From FORRERJ@frl.orst.edu Tue Aug 01 11:58:39 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id LAA29049 for <hfsig@tapr.org>; Tue, 1 Aug 1995 11:58:34 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id JAA22686 for <hfsig@tapr.org>; Tue, 1 Aug 1995 09:58:26 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 1 Aug 95 10:03:25 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Aug 95 10:03:21 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 1 Aug 1995 10:03:18 PST8PDT
Subject:       Re: [HFSIG:505] DWAIT/DTIME/T2 KISS parameter number
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <6E895C81979@frl.orst.edu>

Hi all,

I am not sure that everyone picked up Timo's question and request for help?

We need to know some information on the KISS protocol: does anyone know 
what the KISS parameter (code) for T2/Dwait/Dtime is? 
Who might know? Any help will be greatly appreciated.

Thanks in advantage.

--Johan, KC7WW

 
From k5yfw@sacdm10.kelly.af.mil Tue Aug 01 17:33:17 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id RAA32423 for <hfsig@tapr.org>; Tue, 1 Aug 1995 17:32:53 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sdPgj-0002AnC; Tue, 1 Aug 95 17:21 CDT
Message-Id: <m0sdPgj-0002AnC@sacdm10.kelly.af.mil>
Date: Tue, 1 Aug 95 17:21:25 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:507] Re: DWAIT/DTIME/T2 KISS parameter number
To: hfsig@tapr.org
X-orig-date: Tue, 1 Aug 1995 12:12:13 -0500
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu>
X-orig-message-ID: <6E895C81979@frl.orst.edu>

In your message of  1 Aug 1995 at 1212 CDT, you write:
> Hi all,
>
> I am not sure that everyone picked up Timo's question and request for help?
>
> We need to know some information on the KISS protocol: does anyone know
> what the KISS parameter (code) for T2/Dwait/Dtime is?
> Who might know? Any help will be greatly appreciated.
>
> Thanks in advantage.
>
> --Johan, KC7WW
>
>
>


I'm not at home now so can't get the information but Timo might try
sending the request to nos-bbs@hydra.carleton.ca or tcp-group@ucsd.edu

73, Walt/K5YFW
From FORRERJ@frl.orst.edu Tue Aug 01 18:33:43 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id SAA00059 for <hfsig@tapr.org>; Tue, 1 Aug 1995 18:33:38 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id QAA25539 for <hfsig@tapr.org>; Tue, 1 Aug 1995 16:33:29 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Tue, 1 Aug 95 16:38:29 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 1 Aug 95 16:38:23 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 1 Aug 1995 16:38:14 PST8PDT
Subject:       Re: [HFSIG:508] Re: DWAIT/DTIME/T2 KISS parameter number
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <6EF2B78637E@frl.orst.edu>

Hi Walt,

Good idea.

I don't think either Timo or I am subsribed there - could
you do us a favor pse: cross-post and forward any feedback?

Thanks much.

--Johan

>In your message of  1 Aug 1995 at 1212 CDT, you write:
>> Hi all,
>>
>> I am not sure that everyone picked up Timo's question and request for 
help?
>>
>> We need to know some information on the KISS protocol: does anyone know
>> what the KISS parameter (code) for T2/Dwait/Dtime is?
>> Who might know? Any help will be greatly appreciated.
>>
>> Thanks in advantage.
             ^^^^^^^^^^ thats a new one - hi.

>>
>> --Johan, KC7WW
>>
>>
>>


>I'm not at home now so can't get the information but Timo might try
>sending the request to nos-bbs@hydra.carleton.ca or tcp-group@ucsd.edu
>
>73, Walt/K5YFW
From k5yfw@sacdm10.kelly.af.mil Wed Aug 02 08:10:24 1995
Received: from sacdm10.kelly.af.mil (sacdm10.kelly.af.mil [137.242.64.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id IAA08454 for <hfsig@tapr.org>; Wed, 2 Aug 1995 08:10:11 -0500
Received: by sacdm10.kelly.af.mil (Smail3.1.29.0 #2)
	id m0sddHp-000299C; Wed, 2 Aug 95 07:52 CDT
Message-Id: <m0sddHp-000299C@sacdm10.kelly.af.mil>
Date: Wed, 2 Aug 95 07:52:37 -0500
From: k5yfw@sacdm10.kelly.af.mil (WALT DUBOSE - K5YFW)
Subject: Re: [HFSIG:509] Re: DWAIT/DTIME/T2 KISS parameter number
To: tcp-group@ucsd.edu
Cc: hfsig@tapr.org
X-orig-date: Tue, 1 Aug 1995 18:44:19 -0500
X-orig-from: "Johan Forrer" <FORRERJ@frl.orst.edu>
X-orig-message-ID: <6EF2B78637E@frl.orst.edu>

Could someone answer Timo's question and send the reply to:

        hfsig@tapr.org

Thanks,  Walt/K5YFW

In Timo's message of  1 Aug 1995 at 11212 CDT, he writes:
>
> I need to know some information on the KISS protocol: does anyone know
> what the KISS parameter (code) for T2/Dwait/Dtime is?
> Who might know? Any help will be greatly appreciated.
>
> Thanks in advance, Timo
From wd6ehr@kaiwan.com Wed Aug 02 12:57:22 1995
Received: from kaiwan.kaiwan.com (kaiwan.kaiwan.com [198.178.203.2]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id MAA11570 for <hfsig@tapr.org>; Wed, 2 Aug 1995 12:57:17 -0500
Received: from kaiwan009.kaiwan.com (2070@kaiwan009.kaiwan.com [198.178.203.9]) by kaiwan.kaiwan.com (8.6.12/8.6.12) with ESMTP
	id KAA17382 for <hfsig@tapr.org>; Wed, 2 Aug 1995 10:57:08 -0700
	*** KAIWAN Internet Access ***
Received: (from wd6ehr@localhost) by kaiwan009.kaiwan.com (8.6.9/8.6.9)
	  id KAA13871 for hfsig@tapr.org; Wed, 2 Aug 1995 10:57:10 -0700
	  *** KAIWAN Internet Access ***
From: Mike Curtis <wd6ehr@kaiwan.com>
Message-Id: <199508021757.KAA13871@kaiwan009.kaiwan.com>
Subject: re: DWAIT and KISS
To: hfsig@tapr.org
Date: Wed, 2 Aug 1995 10:57:10 -0700 (PDT)
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 196       

There is no DWAIT in KISS (fortunately!)  It has been replaced by persist
and slottime, which is vastly superior to the old DWAIT parameter.  Also,
Ppersist is incompatible with DWAIT.


 -- mike
From karn@qualcomm.com Wed Aug 02 17:08:09 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA14776 for <hfsig@tapr.org>; Wed, 2 Aug 1995 17:07:52 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id PAA29619; Wed, 2 Aug 1995 15:07:45 -0700
Date: Wed, 2 Aug 1995 15:07:45 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508022207.PAA29619@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: FFT speeds?

I wasn't happy with any of the FFT routines I found on the net or in
textbooks, so over the weekend I wrote up one in C. It does a 256-point
double precision complex FFT in 870 microseconds on the Pentium 90
and 3.34 milliseconds on the AMD 486DX4-100. Anybody have some comparative
speed figures?

Phil

From FORRERJ@frl.orst.edu Wed Aug 02 18:01:56 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id SAA15482 for <hfsig@tapr.org>; Wed, 2 Aug 1995 18:01:43 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id QAA01464 for <hfsig@tapr.org>; Wed, 2 Aug 1995 16:01:29 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 2 Aug 95 16:06:32 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 2 Aug 95 16:06:21 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 2 Aug 1995 16:06:16 PST8PDT
Subject:       Re: [HFSIG:512] FFT speeds?
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <706A3735912@frl.orst.edu>

Phil,

> I wasn't happy with any of the FFT routines I found on the net or in
> textbooks, so over the weekend I wrote up one in C. It does a 256-point
> double precision complex FFT in 870 microseconds on the Pentium 90
> and 3.34 milliseconds on the AMD 486DX4-100. Anybody have some comparative
> speed figures?
> 
> Phil

Could you tell us whether this is floating point or integer, and what
radix ? Sounds very impressive. Just for sake of comparison,
the 12 mHz ADSP-21xx benchmark for a Radix 4, 256 point integer FFT is 
590 us. The 1024 point R4 checks in at 2.98 ms. Radix 2 is nearly double 
those figures. All these are complex, 16-bit data words.

I am sure that you will get a reasonable answer if you post this question 
to COMP.DSP - this is a popular topic.

--Johan

From kurpiers@zeus.uet.e-technik.th-darmstadt.de Thu Aug 03 02:02:19 1995
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id CAA20878 for <hfsig@tapr.org>; Thu, 3 Aug 1995 02:02:07 -0500
Received: from zeus (zeus.uet.e-technik.th-darmstadt.de) by rs2.hrz.th-darmstadt.de with SMTP id AA26851
  (5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Thu, 3 Aug 1995 09:01:17 +0200
Received: from hades (hades.uet.e-technik.th-darmstadt.de [130.83.18.78]) by zeus (8.6.9/8.6.9-HRZ) with ESMTP id JAA20568 for <hfsig@tapr.org>; Thu, 3 Aug 1995 09:01:17 +0200
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de>
Received: (kurpiers@localhost) by hades (8.6.9/8.6.9-HRZ-Fwd2.0) id JAA18701 for hfsig@tapr.org; Thu, 3 Aug 1995 09:01:10 +0200
Message-Id: <199508030701.JAA18701@hades>
Subject: re: DWAIT and KISS
To: hfsig@tapr.org
Date: Thu, 3 Aug 1995 09:01:04 +0200 (MESZ)
In-Reply-To: <199508021757.KAA13871@kaiwan009.kaiwan.com> from "Mike Curtis" at Aug 2, 95 01:01:53 pm
X-Mailer: ELM [version 2.4 PL24]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1093      

> 
> There is no DWAIT in KISS (fortunately!)  It has been replaced by persist
> and slottime, which is vastly superior to the old DWAIT parameter.  Also,
> Ppersist is incompatible with DWAIT.
> 
> 
>  -- mike
> 
Actually the problem (at least with some implementations of KISS on TNC2)
is, that they do not start with the slottime. Depending on the
persistance setting these KISS versions start to transmit immediately
after DCD is gone.
Better would be to wait at least one time slottime before starting
the persistance algorithm.


Alexander


-- 
*----------------------------------+---------------------------------------*
|      Alexander F. Kurpiers       |                                       |
| Institut f. Uebertragungstechnik | Voice: +49-6151-162369                |
|    u. Elektroakustik             | Fax  : +49-6151-165545                |
| Merckstrasse 25                  | EMail: a.kurpiers@uet.th-darmstadt.de |
| D-64283 Darmstadt (Germany)      | Hamradio: dl8aau@db0eam.#hes.deu.eu   |
*----------------------------------+---------------------------------------*


From Sivula@ncsmsg01es.ntc.nokia.com Thu Aug 03 04:31:52 1995
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id EAA21247; Thu, 3 Aug 1995 04:31:45 -0500
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi [131.228.138.80]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id MAA24328; Thu, 3 Aug 1995 12:30:14 +0300
Received: by ntcite01es.ntc.nokia.com with Microsoft Mail
	id <3020A5AE@ntcite01es.ntc.nokia.com>; Thu, 03 Aug 95 12:32:14 eet
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>, "'TAPR-TNC'" <tapr-tnc@tapr.org>
Subject: T2/Dwait/Dtime
Date: Wed, 02 Aug 95 09:25:00 eet
Message-ID: <3020A5AE@ntcite01es.ntc.nokia.com>
Encoding: 21 TEXT
X-Mailer: Microsoft Mail V3.0


Hello,

I checked some documents out and found that Dtime and Dwait are one 
parameter and T2 is another. T2 simply seems to be the  parameter which is 
called Resptime in for instance the G8BPQ manual.

Dwait and Dtime is according to the TheFirmware 2.6 manual a parameter that 
puts a waiting time between the moment when the transmission is intended to 
start to the moment when it is really starting. This is the parameter for 
which I would need the KISS parameter code.

According to the TF manual dwait/dtime is using the value of one timslot of 
the persistence algorithm. Thus the modification consist of simply adding 
one timeslot before every transmisson. I have seen this time beeing 
independently adjustable in some applications, so I would like to be sure 
about how the parameter really works and to get the KISS code for it, if 
there is one.

Timo

From Danny@edstks1.demon.co.uk Thu Aug 03 13:12:54 1995
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id NAA26366 for <hfsig@tapr.org>; Thu, 3 Aug 1995 13:12:46 -0500
Received: from post.demon.co.uk by disperse.demon.co.uk id aa01858;
          3 Aug 95 18:13 +0100
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa02140;
          3 Aug 95 18:10 +0100
Date: Thu, 03 Aug 1995 17:32:23 GMT
From: Danny Higgins <Danny@edstks1.demon.co.uk>
Reply-To: Danny@edstks1.demon.co.uk
Message-Id: <229@edstks1.demon.co.uk>
To: hfsig@tapr.org
Subject: Robust modems
X-Mailer: PCElm 1.10
Lines: 121

Hi, Johan, and many thanks for pointing me at HFSIG.
I've downloaded the discussions for the past year, and I have a lot of reading
to do!

Let me introduce myself. I have been active on HF for 27 years now, mainly CW,
and my main interest is chasing DX with modest power and a small garden. I have
never owned a linear or a beam but I wouldn't call myself a QRP fanatic. My
interest is in robust, reliable HF communications, both professionally and at
home. This has tended towards robust slow speed data, not high speed data
transfer which is available via internet, etc.

For many years now I have been interested in coherent CW as a robust HF
modulation system. Over the years I have been involved in several projects at
work which could lend themselves to improving the CCW waveform.

Basic CCW requires 100 milliseconds for a dot, 300 milliseconds for a dash,
with the gaps between dots and dashes as exact multiples of 100 milliseconds,
giving a Morse speed of 12 WPM. The difficulty with this is the frequency
accuracy required and the synchronisation between both ends of the link. In
practice, a 9Hz wide non-ringing integrate and dump filter can be used
effectively to detect the tones once the signal has been found. The integrate
and dump filter compares its output at the end of every dot period with the
no-signal condition to determine if the carrier was present.

Imagine now the effect of sending a different tone for the key-up condition.
This signal would be 10Hz away from the key-down signal (assuming a 100
millisecond dot length, since the tones must be orthogonal). The key-up signal
is effectively another CCW signal which can be detected in the same way, but
now the data decision is based on the difference between the key-up and
key-down tone detectors. This must give a 3 dB improvement in signal to noise 
ratio at the expense of another coherent tone detector (free if you are using 
DSP!). This is a 2 tone version of the 32 tone Piccolo system.

There is still the problem of synchronisation. Instead of having one tone for 
key-up and another tone for key-down, suppose that a pair of tones are used,
each lasting 50 milliseconds and they must now be 20Hz apart to retain
orthogonality. Let the tones be called Mark (M) and Space (S). Let a DOT be
represented by "SS" and a DASH be represented by "MM". The key-up condition
can be represented by:
                        "MSMSMSMSMSMS...."

The sequence "SM" is invalid and shows that either an error has occurred or
the system is out of sync.

The receiving system can automatically synchronise to a stream of
"....MSMSMSMS..." tones at the start of a transmission. Three detectors can
be used at the decoder, one sampling early, one in the middle and one sampling
late. The relative outputs of these detectors can be used to automatically 
advance and retard the sampling signals to achieve synchronisation (again this
is cheap in DSP but expensive in a custom hardware solution).

Since a DASH contains no more information than a DOT there is no reason for it
to be 3 times longer. The gap between DOTS and DASHES also does not need to be
sent, since the detector can uniquely identify them. The word "PARIS" for
example would be:
                  "SSMMMMSSMSSSMMMSSSMMSSMSSSSSMSSSSSSS"

using "MS" to define the boundary between individual letters. This coding
gives an effective 36 WPM based on the current Morse alphabet and a 100
millisecond tone pair sequence. In practice this can be improved further 
still because the original Morse alphabet was devised with a DASH being 3
times longer than a DOT. In this system the time taken to send the letter "I"
is the same as the time taken to send to letter "M", so a more optimum coding
system could be devised based on the frequency of use of all characters
(including numbers). The complexity of the code doesn't matter because it
will all be done by the machine. The code could also be extended to have short
unique sequences for commonly used combinations of characters (e.g. QTH, QSY,
599, etc.). A speed in excess of 40 or 50 WPM could easily be achieved and the
50 millisecond tone length, which is a long time on HF, is much longer than 
any path delays therefore there should be no inter-symbol interference. This
system is basically a 2 tone version of 6 tone Piccolo (LA1117).

Having produced a code with 20Hz shift, it is possible to chop this with a
pseudo random sequence (direct sequence spread spectrum) in such a way that 
the signal occupies a 3 kHz bandwidth. It is theoretically possible to obtain
about 30 dB of signal to interference rejection this way, on top of the
processing gain already achieved by coherent detection. Different QSOs could 
co-exist in the same channel if different spreading codes are used, or
narrowband signals could be retained for spectrum efficiency (it is also
easier to hear someone calling CQ).

Error detecting and correcting codes could also be applied for additional
robustness.

I have worked for 3 UK communications companies, two using Piccolo on HF and
the other using narrowband (<3 kHz) direct sequence spread spectrum on HF.
It would be nice to combine the advantages of both.

This note is very similar to one sent to Jim Mortenson, N2HOS, at the American
Digital Radio Society (to which I now subscribe) and may be printed in the
July issue.

On the subject of DSP platforms, I have just purchased a P38 DSP modem card
from HAL Communications, and have the EVM5X evaluation module for the
TMS320C50. Since the software is all downloadable from the PC, it should be
possible for someone to implement something like this to run on existing
hardware and therefore get a lot of people up and running fast with these new
modes. This was always the problem with the old CCW system, since it required
people to build filters which were inflexible. What about a stand-alone box
with a morse input and output which would plug into a rig and not require a
computer?

On the subject of external frequency standard inputs for amateur receivers
- beware that some rigs use an internal standard for the synthesizer, then
mix it with a free running crystal oscillator to get it on the right band!

On the subject of time standards - yes a cheap MSF (a UK 60 kHz time standard
transmission) receiver can be built and software exists to take the demodulated
time signal through a pin on the printer socket to automatically update the PC
clock. (This can then be used in a system to monitor the international
chirpsounder network on quiet spot frequencies using a matched DSP filter to
identify particular emitters by their time/frequency offset and provide 
real-time frequency propagation information).

Keep up the good work!!

73s for now, de Danny Higgins, G3XVR


-- 
Danny Higgins
From jreuter@lykos.tng.oche.de Thu Aug 03 14:44:33 1995
Received: from campino.informatik.rwth-aachen.de (campino.Informatik.RWTH-Aachen.DE [137.226.225.2]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id OAA27195 for <hfsig@tapr.org>; Thu, 3 Aug 1995 14:44:00 -0500
Received: from downtown.oche.de ([194.94.253.3]) by campino.informatik.rwth-aachen.de 
        (4.1/campino-8) id AA05051; Thu, 3 Aug 95 21:43:43 +0200 
Received: (from jreuter@localhost) by lykos.tng.oche.de id RAA04463; Wed, 2 Aug 1995 17:36:37 GMT
Date: Wed, 2 Aug 1995 17:36:36 +0000 (GMT)
From: Joerg Reuter <jreuter@lykos.tng.oche.de>
To: WALT DUBOSE - K5YFW <k5yfw@sacdm10.kelly.af.mil>
Cc: hfsig@tapr.org
Subject: Re: [HFSIG:509] Re: DWAIT/DTIME/T2 KISS parameter number
In-Reply-To: <m0sddHp-000299C@sacdm10.kelly.af.mil>
Message-Id: <Pine.LNX.3.91.950802170125.3628A@lykos.tng.oche.de>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 2 Aug 1995, WALT DUBOSE - K5YFW wrote:

> Could someone answer Timo's question and send the reply to:
> 
>         hfsig@tapr.org

Is this another mailing list?

> 
> Thanks,  Walt/K5YFW
> 
> In Timo's message of  1 Aug 1995 at 11212 CDT, he writes:
> >
> > I need to know some information on the KISS protocol: does anyone know
> > what the KISS parameter (code) for T2/Dwait/Dtime is?
> > Who might know? Any help will be greatly appreciated.
> >
> > Thanks in advance, Timo

T2 is an AX.25 Level 2 parameter, not a KISS parameter. If this
timer expires, the whole received packet will be acknowledged
trough a RR. A too small T2 will result in an frame-per-frame
ack. (with TheFirmare below version 2.6 you will sometimes
see cascades of RR-frames after a frame if you set T2 too low:
RR1 / RR2 / RR3 / ...)

DWait --- You probably think of the time the TNC waits after
DCD went down before it starts to transmit. This is done with
the P-Persistence (sp?) / Slottime algorithm.


wait until DCD down  <-------------------------------------+
                                                           |
  |                                                        |
  |                                                        |
  v                                                        ^
                                                           .
wait until waittime expires  :                             .
                             : optional, implemented in    .
  |                          : PE1CHL's SCC driver and
  |                          : the Z8530drv for Linux,
  v                          : perhaps other drivers,
                             : too?
DCD still down?              :
                             :
  |                          :
  | yes                      :
  v                          :

Generate random number <--------------------------------+
                                                        |
  |                                                     |
  |                                                     |
  v                                                     |
                                                        |
number below "persistence" value?                       |
                                                        |
  |                           |                         |
  | yes                       | no                      |  
  v                           v                         |
                                                        |
start to transmit        wait until slottime expires    |
=================                                       |
                              |                         |
                              |                         |
                              v                         |
                                                        |
                         DCD still down?                |
                                                        |  .
                            | no  |                     |  .
                            |     | yes                 |  .
                            |     |                     |  ^
                            |     +---------------------+  |
                            |                              |
                            +------------------------------+

KISS usually supports at least the following commands:

  0 - Data		(of course!)
  1 - Tx delay          (timer)
  2 - persistence       (value)
  3 - slottime          (timer)
  4 - tx tail           (timer)
  5 - fullduplex        (flag)
255 - reset KISS mode   (or return to Hostmode)

all timers in 1/10 s

Joerg Reuter	ampr-net: dl1bke@db0pra.ampr.org
		AX-25   : DL1BKE @ DB0LJ.#RPL.DEU.EU
		Internet: jreuter@lykos.tng.oche.de

From karn@qualcomm.com Thu Aug 03 15:42:12 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id PAA27790 for <hfsig@tapr.org>; Thu, 3 Aug 1995 15:42:08 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id NAA08011; Thu, 3 Aug 1995 13:42:05 -0700
Date: Thu, 3 Aug 1995 13:42:05 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508032042.NAA08011@servo.qualcomm.com>
To: hfsig@tapr.org
Subject: Remez exchange algorithm code?

Does anybody have a machine-readable copy of the Remez exchange
algorithm code for designing FIR filters? There's a FORTRAN listing in
Rabiner & Gold that I'd like to avoid typing in (and translating to C)
if possible. SOMEBODY out there must have it, right?

Phil
From paul@paccomm.com Thu Aug 03 16:52:04 1995
Received: from paccomm.com ([163.125.30.1]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id QAA28497 for <hfsig@tapr.org>; Thu, 3 Aug 1995 16:51:49 -0500
X-BBS-Msg-Type: P
Date: Thu, 03 Aug 95 17:50:10 UTC
Message-Id: <2698@paccomm.com>
From: paul@paccomm.com
To: hfsig@tapr.org
Subject: Re: [HFSIG:516] Robust modems
In-Reply-To: your message of Thu, 3 Aug 1995 13:28:08 -0500.
             <2664@paccomm.com>

CCW timing is easy....
derive your timing from GPS time. You'll then be accurate to around
40ns for the best receivers or a more typical value of 250ns.....

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    .
Paul Evans, W4/G4BKI  paul@paccomm.com  +1 (813) 874-2980    |\
Fax:+1 (813) 872-8696                                       /| \
Views expressed here are not necessarily those of PacComm  / |--\
Don't surf the net, SAIL it!                              /  |   \
Captain of S/V "Spindrift", Dunedin, FL.                 /   |----\
Tall rig (58'), Winged Keel (4' 2"), full batten main   /    |     \
                                                       /-----|------` |
PacComm Packet Radio Systems                          `------`--------]
4413 N. Hesperides St., Tampa, FL 33614-7618           \_____________/
                                                   ~~~~~~~~~~~~~~~~~~~~~~~
                                                             
From forrerj@ucs.orst.edu Thu Aug 03 21:09:02 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id VAA30718 for <hfsig@tapr.org>; Thu, 3 Aug 1995 21:08:42 -0500
Received: from p02.t0.monrotel.com by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA08515; Thu, 3 Aug 1995 19:08:34 -0700
Message-Id: <9508040208.AA08515@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 03 Aug 1995 18:22:09 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:518] Remez exchange algorithm code?

>Does anybody have a machine-readable copy of the Remez exchange
>algorithm code for designing FIR filters? There's a FORTRAN listing in
>Rabiner & Gold that I'd like to avoid typing in (and translating to C)
>if possible. SOMEBODY out there must have it, right?
>
>Phil
>

I uploaded a package to ftp.tapr.org tapr/SIG/hfsig/upload/remez.zip that you
might want to look at. It contains both 16 and 32-bit versions including C
source code. The author is Egil Kvaleberg and I think he did a nice job.

I have a Fortran version as well - it may well be the one in Rabiner and
Gold, if you are interested in that, let me know.

--Johan

From Sivula@ncsmsg01es.ntc.nokia.com Fri Aug 04 02:13:59 1995
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA03888; Fri, 4 Aug 1995 02:13:53 -0500
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi [131.228.138.80]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id KAA21876; Fri, 4 Aug 1995 10:12:23 +0300
Received: by ntcite01es.ntc.nokia.com with Microsoft Mail
	id <3021D6E2@ntcite01es.ntc.nokia.com>; Fri, 04 Aug 95 10:14:26 eet
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>, "'TAPR-TNC'" <tapr-tnc@tapr.org>
Subject: KISS Info received, Thank you.
Date: Fri, 04 Aug 95 10:05:00 eet
Message-ID: <3021D6E2@ntcite01es.ntc.nokia.com>
Encoding: 16 TEXT
X-Mailer: Microsoft Mail V3.0


Hello everybody!

I have received awhole bunch of information concerning KISS. Thank you very 
much
for putting time on this! We have now made the modification to Leonid and 
Beta-testing
is going on.

Thus there is no need for more replys.

Thank you very much, all the help from everyone was very much appreciated.


Timo OH6KK/OH2LVZ
 
From Sivula@ncsmsg01es.ntc.nokia.com Fri Aug 04 02:14:10 1995
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id CAA03900 for <hfsig@tapr.org>; Fri, 4 Aug 1995 02:14:02 -0500
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi [131.228.138.80]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id KAA21885 for <hfsig@tapr.org>; Fri, 4 Aug 1995 10:12:33 +0300
Received: by ntcite01es.ntc.nokia.com with Microsoft Mail
	id <3021D6EB@ntcite01es.ntc.nokia.com>; Fri, 04 Aug 95 10:14:35 eet
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>
Subject: RE: [HFSIG:517] Re: DWAIT/DTIME/T2 KISS parameter number
Date: Fri, 04 Aug 95 10:06:00 eet
Message-ID: <3021D6EB@ntcite01es.ntc.nokia.com>
Encoding: 14 TEXT
X-Mailer: Microsoft Mail V3.0


>T2 is an AX.25 Level 2 parameter, not a KISS parameter.

I didn't know that before, but I do know it now! Thanks to everyone
who bothered answering!

>I A too small T2 will result in an frame-per-frame
>ack. (with TheFirmare below version 2.6 you will sometimes
>see cascades of RR-frames after a frame if you set T2 too low:
>RR1 / RR2 / RR3 / ...)

To me it seems like most KISS TNC's do this anyway.

Timo
From karn@qualcomm.com Fri Aug 04 05:34:50 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id FAA04766 for <hfsig@tapr.org>; Fri, 4 Aug 1995 05:34:45 -0500
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id DAA08159; Fri, 4 Aug 1995 03:34:37 -0700
Date: Fri, 4 Aug 1995 03:34:37 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199508041034.DAA08159@unix.ka9q.ampr.org>
To: FORRERJ@frl.orst.edu
CC: hfsig@tapr.org
Reply-To: karn@qualcomm.com
In-reply-to: <706A3735912@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:513] Re: FFT speeds?

>Could you tell us whether this is floating point or integer, and what
>radix ? Sounds very impressive. Just for sake of comparison,

Floating point -- double precision. The butterflies are all radix 2,
though I do optimize out the complex multiplies in the cases where the
twiddle factors are 1 and -j. Avoiding the complex multiply in the
latter case is what gives the radix 4 FFT most of of its advantage.

Wednesday night I used it in a bandpass filter that works by fast
convolution with overlap+add. It's a hack I needed to filter some test
audio that I'm working into a digital voice demo to complement the one
I already did for CW vs PSK with FEC. The idea is to produce a
synthetic noisy SSB signal that uses the same satellite transponder
energy as a vocoded speech signal at some data rate (either 13kb/s for
the GSM coder or 8kb/s for the Qualcomm QCELP coder) over a modem with
some specified EB/N0.

The big question in any power efficiency comparison of digital voice
to SSB is the target audio S/N ratio to be used in the comparison. If
a high S/N ratio is required, the digital scheme is clearly the
winner.  But if people are willing to tolerate very low SSB S/N
ratios, it's harder for the digital scheme to save power. And I have a
rather poor quantitative feel for what various SSB S/Ns really sound
like, hence my experiments.

Phil

From FORRERJ@frl.orst.edu Fri Aug 04 10:26:26 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id KAA07813 for <hfsig@tapr.org>; Fri, 4 Aug 1995 10:26:20 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA10786 for <hfsig@tapr.org>; Fri, 4 Aug 1995 08:26:02 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Fri, 4 Aug 95 8:31:08 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Fri, 4 Aug 95 8:30:54 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Fri, 4 Aug 1995 08:30:53 PST8PDT
Subject:       Re: [HFSIG:516] Robust modems
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <72F0D5C7F2D@frl.orst.edu>

Hi Danny,

First - let me welcome both you and Paul Evans to HFSIG. We are looking 
forward sharing in your ideas and talents.

I have had several requests lately from folks that read this SIG asking for 
more basic materials at a level for the average ham. This is something that 
I intend doing for future HFSIG columns in PSR, however, once I have a 
bit more free time - so please be patient in the mean time. That brings me 
to CCWW:

CCW, in my opinion, is probably one of the neatest ways of learning DSP 
from the ground up. Especially now with these low-cost EVM's, and all those 
DSP-93's out there, maybe the time is ripe for someone like you to develop 
some DSP code and write about it so that we can get more folks involved and 
participating. 

I am aware of at least two CCW programs out there - one is based on the 
work of Bill de Carle, VE2IQ (?) that runs on a PC and uses his very simple 
sigma-delta A/D convertor (described in QST and QEX). The output of this 
program is computer-generated tones - the operator still has to decode the 
CW by ear though. This would be a great first step to learn DSP principles -
 mostly, common sense is involved (assuming the operator can decode CW by 
ear). Then there is another CCW program by a DL ham (sorry I don't recall 
his name) that takes this another step further - it actually decodes and 
prints the CW.

Your suggestion of a two-tone signalling system sounds intriguing - 
however, we loose the ability to decipher the CW by ear. Hold the thought 
for the moment - I like your idea for extending CCW to a narrow-band SS 
system. This may perhaps be the breakthrough that we are waiting for! How 
does it sound, if after you get regular CCW working, implementing the SS 
feature. Regular narrow-band CCW is used to call CQ, sinchronise and 
establish the link -  the mode is then switched over to SS. The main 
requirement is that it must be possible for monitoring the transmission by 
a third party - I am sure that with some ingenuity, this may be possible.  
It probably will require that US amateurs apply for STA to participate, but 
would'nt that be a wonderful opportunity to get exposed to these 
contemporary concepts?

Good luck with your project. Keep us posted on your progress and let us 
know how we can help.

73's

--Johan, KC7WW

    
From karn@qualcomm.com Fri Aug 04 17:20:29 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id RAA12320 for <hfsig@tapr.org>; Fri, 4 Aug 1995 17:20:24 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id PAA17024; Fri, 4 Aug 1995 15:20:02 -0700
Date: Fri, 4 Aug 1995 15:20:02 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508042220.PAA17024@servo.qualcomm.com>
To: paul@paccomm.com
CC: hfsig@tapr.org
In-reply-to: <2698@paccomm.com> (paul@paccomm.com)
Subject: Re: [HFSIG:519] Re: Robust modems

>CCW timing is easy....
>derive your timing from GPS time. You'll then be accurate to around
>40ns for the best receivers or a more typical value of 250ns.....

Except, of course, for the effects of signal propagation delay...

Phil
From chbrain@dircon.co.uk Sun Aug 06 00:46:25 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with SMTP id AAA27812 for <hfsig@tapr.org>; Sun, 6 Aug 1995 00:46:21 -0500
Received: by felix.dircon.co.uk id AA22825
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sun, 6 Aug 1995 06:45:42 +0100
Message-Id: <199508060545.AA22825@felix.dircon.co.uk>
Received: from ac043.pool.dircon.co.uk(193.128.230.43) by amnesiac via smap (V1.3)
	id sma022823; Sun Aug  6 06:45:24 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 06 Aug 1995 05:39:48 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: MIL-STD-188-141A

If anyone is interested there is a postscript copy of the ALE mil standard
and a final draft of the proposed H.F data link protocol for use with FS1052
and some psk code and even some viterbi stuff on....

ftp://atanasoff.nmsu.edu/pub/hf
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From karn@unix.ka9q.ampr.org Sun Aug 06 01:06:55 1995
Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.90.35]) by dingus.n5lyt.datarace.com (8.6.12/8.6.9) with ESMTP id BAA27919 for <hfsig@tapr.org>; Sun, 6 Aug 1995 01:06:52 -0500
Received: (from karn@localhost) by unix.ka9q.ampr.org (8.6.12/8.6.12) id XAA10906; Sat, 5 Aug 1995 23:06:48 -0700
Date: Sat, 5 Aug 1995 23:06:48 -0700
From: Phil Karn <karn@unix.ka9q.ampr.org>
Message-Id: <199508060606.XAA10906@unix.ka9q.ampr.org>
To: hfsig@tapr.org, tcp-group@ucsd.edu
Subject: FEC packages updated

I've put out updated versions of the Fano and Viterbi decoder packages
I originally released in March.

The changes aren't extensive; mostly minor bug fixes and some cosmetic
reworking. They're described in the new readme files. My web page

http://www.qualcomm.com/people/pkarn/ham.html

has been updated to point to the updated files.

Note: since the files themselves reside in ftp.ucsd.edu's anonymous
upload directory, I was unable to overwrite or delete the old
versions. So I had to create new file names. Flush any old copies you
may have of the web page mentioned above.

Phil

From Danny@edstks1.demon.co.uk Fri Aug 11 08:02:23 1995
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id IAA15822 for <hfsig@tapr.org>; Fri, 11 Aug 1995 08:02:08 -0500
Received: from post.demon.co.uk by disperse.demon.co.uk id aa00849;
          11 Aug 95 13:27 +0100
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa06076;
          11 Aug 95 13:24 +0100
Date: Fri, 11 Aug 1995 12:38:00 GMT
From: Danny Higgins <Danny@edstks1.demon.co.uk>
Reply-To: Danny@edstks1.demon.co.uk
Message-Id: <236@edstks1.demon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:524] Re: Robust modems
X-Mailer: PCElm 1.10
Lines: 55

In message <72F0D5C7F2D@frl.orst.edu> hfsig@tapr.org writes:
Hi again Johan
 
 
> CCW, in my opinion, is probably one of the neatest ways of learning DSP 
> from the ground up. Especially now with these low-cost EVM's, and all those 
> DSP-93's out there, maybe the time is ripe for someone like you to develop 
> some DSP code and write about it so that we can get more folks involved and 
> participating. 

This is the only reason that I want to get into DSP. I am way down the
learning curve, but I've got the kit and the enthusiasm, all I need now
is time and knowledge!!
  
> I am aware of at least two CCW programs out there - ....

I am aware of these programs, but as you can see I want to take it further.


> Your suggestion of a two-tone signalling system sounds intriguing - 
> however, we loose the ability to decipher the CW by ear.

What I suggested was a modem with a morse key input and loudspeaker output
which sent the reconstituted morse back to the operator, using a FIFO to
balance out the speed differences. With about 50 WPM capability, I reckon
the modem would spend most of its time idling!

> Hold the thought for the moment - 
>I like your idea for extending CCW to a narrow-band SS 
> system. This may perhaps be the breakthrough that we are waiting for! How 
> does it sound, if after you get regular CCW working, implementing the SS 
> feature. Regular narrow-band CCW is used to call CQ, sinchronise and 
> establish the link -  the mode is then switched over to SS. The main 
> requirement is that it must be possible for monitoring the transmission by 
> a third party - I am sure that with some ingenuity, this may be possible.  
> It probably will require that US amateurs apply for STA to participate, but 
> would'nt that be a wonderful opportunity to get exposed to these 
> contemporary concepts?

The Piccolo modem by Adrian Nash would form the basis for this type of CCW
system if it only used 2 tones. I'm trying to get in touch with him since
he is transporting it to the TMS320C50 which I use. Alternatively, why not
keep all 6 tones and still apply direct sequence spread spectrum?

The spreading code would be chosen for its autocorrelation properties, not
as a means of "encrypting" data. The codes would therefore be in the public
domain. Experimental licences have been granted over here, but mainly for
VHF work. I see no reason for not applying this to HF, as long as the signal
was band limited to about 2 or 3 kHz, therefore not requiring a special IF
filter in the receiver/transmitter. I wonder how long it will be before Ham
rigs will generally have DSP IF filters to get round some of these problems.
 

-- 
73s de Danny Higgins, G3XVR
From Danny@edstks1.demon.co.uk Fri Aug 11 08:03:06 1995
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id IAA15846 for <hfsig@tapr.org>; Fri, 11 Aug 1995 08:03:01 -0500
Received: from post.demon.co.uk by disperse.demon.co.uk id aa00883;
          11 Aug 95 13:28 +0100
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa06190;
          11 Aug 95 13:25 +0100
Date: Fri, 11 Aug 1995 12:52:41 GMT
From: Danny Higgins <Danny@edstks1.demon.co.uk>
Reply-To: Danny@edstks1.demon.co.uk
Message-Id: <237@edstks1.demon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:525] Re: Robust modems
X-Mailer: PCElm 1.10
Lines: 20

Hi, Phil.

>CCW timing is easy....
>derive your timing from GPS time. You'll then be accurate to around
>40ns for the best receivers or a more typical value of 250ns.....
> 
> Except, of course, for the effects of signal propagation delay...
> 
> Phil
> 

You could end up paying more for GPS than for the modem! I would hope to
build a small stand alone modem for use with any transceiver.

As someone else pointed out before, if you use GPS timing then you could
use the propagation delay to select (or reject!) signals from particular
areas.

-- 
73s de Danny Higgins, G3XVR
From Danny@edstks1.demon.co.uk Fri Aug 11 08:07:59 1995
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id IAA15909 for <hfsig@tapr.org>; Fri, 11 Aug 1995 08:07:48 -0500
Received: from post.demon.co.uk by disperse.demon.co.uk id aa00795;
          11 Aug 95 13:27 +0100
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa05988;
          11 Aug 95 13:24 +0100
Date: Fri, 11 Aug 1995 12:34:42 GMT
From: Danny Higgins <Danny@edstks1.demon.co.uk>
Reply-To: Danny@edstks1.demon.co.uk
Message-Id: <235@edstks1.demon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:519] Re: Robust modems
X-Mailer: PCElm 1.10
Lines: 10

In message <2698@paccomm.com> hfsig@tapr.org writes:
> CCW timing is easy....
> derive your timing from GPS time. You'll then be accurate to around
> 40ns for the best receivers or a more typical value of 250ns.....
                     
Fine, but you will spend more on GPS than I inteded to on the modem!
I would like to make this an external box which went with any transceiver. 

-- 
Danny Higgins
From sadowskp@usafcrqs.nellis.af.mil Fri Aug 11 10:04:43 1995
Received: from bncc.nellis.af.mil ([132.58.120.19]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id KAA17504 for <hfsig@tapr.org>; Fri, 11 Aug 1995 10:04:37 -0500
Received: from mailgtwy.nellis.af.mil by bncc.nellis.af.mil with SMTP
	(1.38.193.4/16.2) id AA22022; Fri, 11 Aug 1995 08:15:27 -0700
Received: by mailgtwy.nellis.af.mil with Microsoft Mail
	id <302B4A05@mailgtwy.nellis.af.mil>; Fri, 11 Aug 95 07:16:05 cdt
From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:528] Re: Robust modems
Date: Fri, 11 Aug 95 07:18:00 cdt
Message-Id: <302B4A05@mailgtwy.nellis.af.mil>
Encoding: 19 TEXT
X-Mailer: Microsoft Mail V3.0


The comments about the CCW and SS were very interesting (exactly the
kind of thing I was hoping to see in this SIG)..   I'm looking for info on a 

very similar topic, CCW but extremely narrow bandwidth - - 10 Hz max..  I
realize the symbol rate will be slower - but my interested is in sending a
few "canned" msgs - so an appropriate coding scheme can "compress"
a heck of a bunch with only a few fixed messages.  Mind you, I'm not
interested in giving up free text altogether... just that I can accept 
serious
compromise for free text (canned msgs are 95% of need).  I'm going to
show my ignorance here... but what might be the tradeoffs I can expect
by using SS with low symbol rate vs CCW at low rate?  Technology wise,
error rate, propogation anything else???

Thanks in advance
Al
AH6LS
sadowskp@usafcrqs.nellis.af.mil
From forrerj@ucs.orst.edu Fri Aug 11 12:53:57 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id MAA18993 for <hfsig@tapr.org>; Fri, 11 Aug 1995 12:50:14 -0500
Received: from p00.t0.monrotel.com by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA00474; Fri, 11 Aug 1995 10:49:47 -0700
Message-Id: <9508111749.AA00474@ucs.orst.edu>
X-Sender: forrerj@ucs.orst.edu
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 11 Aug 1995 10:03:59 -0800
To: hfsig@tapr.org
From: forrerj@ucs.orst.edu (Johan Forrer)
Subject: Re: [HFSIG:531] Re: Robust modems

Dear Al,


>
>The comments about the CCW and SS were very interesting (exactly the
>kind of thing I was hoping to see in this SIG)..   

I agree - if this kind of approach is taken, it would be a breakthough I
believe.


>I'm looking for info on a 
>very similar topic, CCW but extremely narrow bandwidth - - 10 Hz max.. 

The rationale behind CCW's narrow filter bandwidth, is that it is optimal
(not necessarily minimal) for the symbol length. This is what the theory of
"matched filters" is about. The price that one pays for having such a
special filter is in the compexity in technology/algorithms that precisely
extracts where each symbol start/end, and in addition maintain that with
vengance. This is where men and the mice are separated.

> I
>realize the symbol rate will be slower - but my interested is in sending a
>few "canned" msgs - so an appropriate coding scheme can "compress"
>a heck of a bunch with only a few fixed messages.  Mind you, I'm not
>interested in giving up free text altogether... just that I can accept 
>serious
>compromise for free text (canned msgs are 95% of need).  

Not a bad idea - the "Q" code was intended to do that anyway.


>I'm going to
>show my ignorance here... but what might be the tradeoffs I can expect
>by using SS with low symbol rate vs CCW at low rate?  Technology wise,
>error rate, propogation anything else???
>
>Thanks in advance
>Al
>AH6LS
>sadowskp@usafcrqs.nellis.af.mil
>

I am as ignorant, but let me have a shot at it - I'll let those more
knowledgeable correct me please.

These are two different concepts: 

CCW is a form of coherent demodulation/detection. All that is achieved is
optimal receiving conditions for detecting a signal, given the
signal-to-noise ratio. There is no built-in error detection/correction when
QSB or QRM sets in (except of course that when you dechiper CW by ear, one
tend to "fill in the blanks" and thus intentionally are doing some form of ECC).
Summarized: its strenghts is optimal signal detection for a given S/N. If
there is spare S/N, i.e., good conditions (this probably includes conditions
where regular CW at the same speed would be pretty tough), very low power
can be used. There is nothing special about the emitted CW bandwidth - it is
a regular on-off keyed waveform at the given symbol rate. If there is QRM on
identically the same frequency, thoughput goes down to zero.

SS is a signal spreading mode: Instead of having all the signal energy
concentrated at one frequency, it gets spread out over a much wider band of
frequencies - a couple of kiloherz or megaherz depending. The result is that
a certain degree of redundancy enters the picture - if some portion of the
signal gets blanked out by QRM, or perhaps by selective fading, there
hopefully remains sufficient signal integrity to detect and demodulate the
signal. Once the signal is demodulated into baseband (audio), one can still
use matched filters as for CCW and enjoy the same gains.
Summarized: Strengths lays in robustness and ability to withstand a
substantial degree of interference. When applied wisely, many users may
share the same spectral space, without one interfering with another. Sounds
a bit like magic, does'nt it?


Hope that helps?

73's

--Johan, KC7WW 

From Danny@edstks1.demon.co.uk Mon Aug 14 13:25:25 1995
Received: from disperse.demon.co.uk (disperse.demon.co.uk [158.152.1.77]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id NAA22475 for <hfsig@tapr.org>; Mon, 14 Aug 1995 13:25:19 -0500
Received: from post.demon.co.uk by disperse.demon.co.uk id aa11948;
          14 Aug 95 17:53 +0100
Received: from edstks1.demon.co.uk by post.demon.co.uk id aa20950;
          14 Aug 95 17:50 +0100
Date: Mon, 14 Aug 1995 17:32:07 GMT
From: Danny Higgins <Danny@edstks1.demon.co.uk>
Reply-To: Danny@edstks1.demon.co.uk
Message-Id: <248@edstks1.demon.co.uk>
To: hfsig@tapr.org
Subject: Re: [HFSIG:532] Re: Robust modems
X-Mailer: PCElm 1.10
Lines: 34

> 
> SS is a signal spreading mode: Instead of having all the signal energy
> concentrated at one frequency, it gets spread out over a much wider band of
> frequencies - a couple of kiloherz or megaherz depending. The result is that
> a certain degree of redundancy enters the picture - if some portion of the
> signal gets blanked out by QRM, or perhaps by selective fading, there
> hopefully remains sufficient signal integrity to detect and demodulate the
> signal. Once the signal is demodulated into baseband (audio), one can still
> use matched filters as for CCW and enjoy the same gains.
> Summarized: Strengths lays in robustness and ability to withstand a
> substantial degree of interference. When applied wisely, many users may
> share the same spectral space, without one interfering with another. Sounds
> a bit like magic, does'nt it?
> 
If I can throw a little bit of light on SS -

If you start at the modulator with a clean signal, then spread it over, say a
3 kHz bandwidth by introducing 180 degree phase changes from a pseudo random
code sequence at a rate equal to half (?) the bandwidth required, what you
get is a signal which has a sin(x)/x distribution and sounds quite noiselike.

When this signal appears at the receiver it will have all kinds of QRM
superimposed on it, and usually at a much greater amplitude. When the signal
is de-spread by introducing 180 degree phase changes which are synchronised
to the code sequence which generated the original SS signal, the effect is to
concentrate all of the spread signal energy back into a single (or multiple)
tone modulated waveform, but all of the QRM gets spread by this process, which
gets you your S/N advantage.

Hope this simple non-mathematical description helps to explain where the S/N
advantage comes from.
-- 
73s de Danny Higgins, G3XVR

From FORRERJ@frl.orst.edu Wed Aug 16 14:59:37 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id OAA16174 for <hfsig@tapr.org>; Wed, 16 Aug 1995 14:59:25 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id MAA07757 for <hfsig@tapr.org>; Wed, 16 Aug 1995 12:57:49 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Wed, 16 Aug 95 13:03:24 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 16 Aug 95 13:03:04 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Wed, 16 Aug 1995 13:02:55 PST8PDT
Subject:       HFSIG at the Digital Conference
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <8539EF744A2@frl.orst.edu>

Greetings,

Thought I would let everyone know that we are planning a special 
meeting on the topic of HF digital communications at the upcoming Digital 
Conference.

I will prepare some materials for an update on various projects 
that the folks have been working on, in particular, the parallel OFDM HF 
modem, MFSK (Piccolo) HF modem, and various bits pieces of DSP hardware. 
Time permitting, other interesting technical materials may also be 
presented. However, there will be an opportunity and open invitation to 
bring up your favorite or other pressing matters for discussion. 

Greg also tells me that there would be space for me to set up a demo showing
off a couple of the DSP projects that have been discussed on this SIG. I 
will bring a laptop and some DSP hardware and give you the opportunity to 
see how far things have come along. 

Please make a special effort to be there - looking forward seeing you.

73's

--Johan, KC7WW   






From forrerj@ucs.orst.edu Wed Aug 16 16:56:37 1995
Received: from ucs.orst.edu (UCS.ORST.EDU [128.193.4.5]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id QAA17382 for <HFSIG@tapr.org>; Wed, 16 Aug 1995 16:56:33 -0500
Received: by ucs.orst.edu; (5.65v3.0/1.1.8.2/24Sep94-1201PM)
	id AA03688; Wed, 16 Aug 1995 14:56:31 -0700
Date: Wed, 16 Aug 1995 14:56:31 -0700 (PDT)
From: Johan Forrer <forrerj@ucs.orst.edu>
To: HFSIG@tapr.org
Subject: HFSIG at the Digital Conference
Message-Id: <Pine.OSF.3.91.950816145337.17596A-100000@ucs.orst.edu>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

Greetings,

Thought I would let everyone know that we are planning a special 
meeting on  HF digital communications at the upcoming Digital 
Conference.

I will prepare some materials for an update on various projects 
that the folks have been working on, in particular, the parallel OFDM HF 
modem, MFSK (Piccolo) HF modem, and various bits pieces of DSP hardware. 
Time permitting, other interesting technical materials may also be 
presented. However, this is an opportunity and open invitation to 
share your experiences or bring up other pressing matters for discussion. 

Greg also tells me that there would be space to set up a demo showing
off a couple of the DSP projects that have been discussed on this SIG. I 
will bring a laptop and some DSP hardware and give you the opportunity to 
see how far things have come along. 

Please make a special effort to be there - looking forward seeing you.

73's

--Johan, KC7WW   
From danie.brynard@pixie.co.za Thu Aug 17 23:57:53 1995
Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id XAA01849 for <hfsig@tapr.org>; Thu, 17 Aug 1995 23:57:47 -0500
Received: from pixie.co.za ([196.11.63.137]) by foxbat.pix.za (8.6.12/8.6.12) with SMTP id GAA04197 for <hfsig@tapr.org>; Fri, 18 Aug 1995 06:57:57 +0200
Date: Fri, 18 Aug 1995 06:57:57 +0200
Message-Id: <199508180457.GAA04197@foxbat.pix.za>
X-Sender: pak03226@pixie.co.za
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:535] HFSIG at the Digital Conference

>Greetings,
>
>Thought I would let everyone know that we are planning a special 
>meeting on  HF digital communications at the upcoming Digital 
>Conference.
>

Ai... wens ek kon julle join ! As julle enige van die conference se goed op
magnetiese media gaan he, sal jy asb aan my dink ?

73 danie

From muphaus@cris.com Mon Aug 21 03:07:39 1995
Received: from deathstar.cris.com (deathstar-fddi.cris.com [199.3.12.171]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id DAA05306 for <hfsig@tapr.org>; Mon, 21 Aug 1995 03:07:36 -0500
Received: from mariner.cris.com by deathstar.cris.com [1-800-745-CRIS (voice)]
Errors-To: Muphaus@cris.com
Received: by mariner.cris.com (4.1) id AA16798; Mon, 21 Aug 95 04:07:33 EDT
From: muphaus@cris.com (Marv Uphaus)
Newsgroups: list.tapr.hfsig
To: hfsig@tapr.org
Subject: Analog Devices ADSP 2181 Development kit...
Date: Mon, 21 Aug 1995 02:43:53 -0500
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <5kDOwM82cCKc083yn@cris.com>
References: <199508180457.GAA04197@foxbat.pix.za>
Lines: 38

Johan and All...

Has anyone seen the Analog Devices ADSP 2181 Development kit...???

There's an ad on page 10 of the August 95 issue of Circuit Cellar for the
kit for $89.00...  Looks pretty nice...  I have wanted a stand alone board
with upload capabilities and if the code that Johan and others have already
developed could be cut over to the 2181 chip, this might be just the thing
to do some stand alone development...  It certainly could be just the
vehicle to get folks like me who aren't heavy duty programmers to take a 
shot at using some of this code on the air...  Personally I keep the ham 
shack and the computer development areas separate and I like the stand
alone idea...

Anyone have any feelings for this...  For $89.00 it's worth buying one just
to play with...

Here's the whole poop...

ADSP 2181 chip - 33-MIPS with 32KB words of on-chip memory...  An AD1847
stereo audio SoundPort codec...  Has an RS-232 port and a dual op-amp for
signal conditioning and an EPROM socket for on-board code...  You get an
assembler, linker, simulator and PROM formatter in the software category...

Can be made into a stand alone device...  They even give you an RS-232
cable to go to your PC and a 110V cube to power it...  It has Windows
monitor program to control the whole thing...

WOW, I think I'm sending in my $89.00 today...!!!

-- Marv...

-- For private communications, use my PGP public key --
-- available at MIT public key server or "finger" me --
-- muphaus@cris.com --

"I still think a MegaByte is the most Nine-Lives you can get in your mouth
at one time." --Morris the Cat, sitting in front of his computer terminal.
From FORRERJ@frl.orst.edu Mon Aug 21 10:38:43 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id KAA07963 for <hfsig@tapr.org>; Mon, 21 Aug 1995 10:38:40 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id IAA10564 for <hfsig@tapr.org>; Mon, 21 Aug 1995 08:38:43 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 21 Aug 95 8:43:10 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 21 Aug 95 8:42:58 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 21 Aug 1995 08:42:53 PST8PDT
Subject:       Re: [HFSIG:537] Analog Devices ADSP 2181 Development kit...
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <8C74C8A7BD6@frl.orst.edu>

Hi Marv,

Thanks for letting us know about the EZ-lite. It certainly represents a 
very potent little DSP - plenty of MIPS and lots of on-chip memory. The 24-
bit architecture also is somewhat easier to learn than some others.

However, perhaps you want to hold out getting one until you have seen the 
August QEX for some comparisons. I have been playing with the 
Motorola 56002-based EVM ($150) and the article is about this unit. This 
past weekend I have been testing, and am most impressed, with how the 
high speed HF modem runs on the Motorola EVM. Pawel (SP9VRC) now has a 2500 
bps (without FEC) version that looks very promising. If you are planning on 
attending the DCC, I am planning on showing the setup and give you a first- 
hand opportunity to see what it is about. 

73's

--Johan








From muphaus@cris.com Mon Aug 21 11:18:54 1995
Received: from deathstar.cris.com (deathstar-fddi.cris.com [199.3.12.171]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id LAA08482 for <hfsig@tapr.org>; Mon, 21 Aug 1995 11:18:49 -0500
Received: from mariner.cris.com by deathstar.cris.com [1-800-745-CRIS (voice)]
Errors-To: Muphaus@cris.com
Received: by mariner.cris.com (4.1) id AA26473; Mon, 21 Aug 95 12:18:42 EDT
From: muphaus@cris.com (Marv Uphaus)
To: hfsig@tapr.org
Subject: Re: [HFSIG:538] Re: Analog Devices ADSP 2181 Development kit...
Date: Mon, 21 Aug 1995 11:09:36 -0500
Organization: Not Organized
Reply-To: muphaus@cris.com
Message-Id: <A/KOwM82ciUR083yn@cris.com>
References: <8C74C8A7BD6@frl.orst.edu>
In-Reply-To: <8C74C8A7BD6@frl.orst.edu>
Lines: 21

Johan and All...

On Mon, 21 Aug 1995 10:58:31 -0500, you wrote:

>However, perhaps you want to hold out getting one until you have seen the
>August QEX for some comparisons. I have been playing with the
>Motorola 56002-based EVM ($150) and the article is about this unit.

Too late...!  I got so excited that this morning I ordered one just to play
with...  It's being shipped today...  I hope you guys have not totally 
abandoned the ADSP 2115 project...  At least there is some code out there 
to play with for a small potatoes programmer...

-- Marv...

-- For private communications, use my PGP public key --
-- available at MIT public key server or "finger" me --
-- muphaus@cris.com --

"I still think a MegaByte is the most Nine-Lives you can get in your mouth
at one time." --Morris the Cat, sitting in front of his computer terminal.
From FORRERJ@frl.orst.edu Mon Aug 21 12:00:31 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id MAA09165 for <hfsig@tapr.org>; Mon, 21 Aug 1995 12:00:24 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with SMTP id KAA11161 for <hfsig@tapr.org>; Mon, 21 Aug 1995 10:00:25 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11);
    Mon, 21 Aug 95 10:04:52 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 21 Aug 95 10:04:26 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Mon, 21 Aug 1995 10:04:17 PST8PDT
Subject:       Re: [HFSIG:539] Re: Analog Devices ADSP 2181 Development ki
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <8C8A81B4001@frl.orst.edu>

Hi Marv,

No, the ADI-2115 project is alive and well. As a matter of fact, if you 
show up at the DDC, I will be happy to show you some very neat software 
by Adrian, G4ZHZ, for the PSA soundcard. I won't let the cat out 
of the bag. Adrian also has passed on code to run MFSK - I will be 
starting work on getting it ported to the sound card DSP in the near future.
So, not to worry, there will be plenty of opportunities for you to explore.

One thing that we have to accept for the moment, is that there will be 
several DSP platforms - it will be a while until we will be able  
to present a written specification for the HF modems that is presently 
being developed. When that time comes, it would be necessary to cross-port 
between these platforms, if that is possible. That possibly may be a 
challenge. Judging from what I have seen going on in the high speed HF 
modem, it would be a tough job to match the 56K's performance - the modem 
is very hungry on cycles, and the benifits of the 24-bit architecture has 
its advantages in dynamic range. Anyway we will have to wait and see how it 
develops.

I will present further details of these projects at the DDC and at that 
time invite your inputs on some issues that are presently unfolding. 

--Johan, KC7WW
From paul@paccomm.com Tue Aug 22 09:45:41 1995
Received: from paccomm.com ([163.125.30.1]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id JAA21064 for <hfsig@tapr.org>; Tue, 22 Aug 1995 09:45:28 -0500
X-BBS-Msg-Type: P
Date: Tue, 22 Aug 95 10:38:31 UTC
Message-Id: <4063@paccomm.com>
From: paul@paccomm.com
To: hfsig@tapr.org
Subject: Re: [HFSIG:540] Re: Analog Devices ADSP 2181 Development ki
In-Reply-To: your message of Mon, 21 Aug 1995 12:08:28 -0500.
             <3962@paccomm.com>


Seems like the PTC-II team chose the right DSP to do the HF modem
job.....    the Mot.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    .
Paul Evans, W4/G4BKI  paul@paccomm.com  +1 (813) 874-2980    |\
Fax:+1 (813) 872-8696                                       /| \
Views expressed here are not necessarily those of PacComm  / |--\
Don't surf the net, SAIL it!                              /  | * \
Captain of S/V "Spindrift", Dunedin, FL.                 /   |----\
Catalina 36: Tall rig (58'), Winged Keel (4' 2"),       /    |     \
Full batten main, Boston Whaler dinghy.                /-----|------` |
PacComm Packet Radio Systems                          \------`--------]
4413 N. Hesperides St., Tampa, FL 33614-7618           \_____________/.__.
                                                   ~~~~~~~~~~~~~~~~~~~~~~~
                                                             
From karn@qualcomm.com Tue Aug 22 16:44:37 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id QAA26596 for <hfsig@tapr.org>; Tue, 22 Aug 1995 16:44:31 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id OAA15733; Tue, 22 Aug 1995 14:44:22 -0700
Date: Tue, 22 Aug 1995 14:44:22 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508222144.OAA15733@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <248@edstks1.demon.co.uk> (message from Danny Higgins on Mon, 14 Aug 1995 13:46:23 -0500)
Subject: Re: [HFSIG:533] Re: Robust modems

An additional remark about spread spectrum processing gain -- it's a
wash on a nonfading AWGN (additive white gaussian noise) channel. A
spread system has no signal-to-noise advantage over a non spread
system in this case.

However, SS wins big in several important real-world situations.
These include fading channels, and channels with interference
(intentional or benign). And it's especially helpful where there are
lots of individual users with traffic that's too bursty to permit the
efficient reallocation of channels or timeslots on demand.

Phil

From karn@qualcomm.com Tue Aug 22 17:05:31 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id RAA26920 for <hfsig@tapr.org>; Tue, 22 Aug 1995 17:05:21 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id PAA15792; Tue, 22 Aug 1995 15:05:18 -0700
Date: Tue, 22 Aug 1995 15:05:18 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508222205.PAA15792@servo.qualcomm.com>
To: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil>
CC: hfsig@tapr.org
In-reply-to: <302B4A05@mailgtwy.nellis.af.mil> (sadowskp@usafcrqs.nellis.af.mil)
Subject: Re: [HFSIG:531] Re: Robust modems

>compromise for free text (canned msgs are 95% of need).  I'm going to
>show my ignorance here... but what might be the tradeoffs I can expect
>by using SS with low symbol rate vs CCW at low rate?  Technology wise,
>error rate, propogation anything else???

In general, SS is better at extremely low rates. Extremely narrowband
techniques often have problems with carrier frequency uncertainty and
guard-banding, and SS can be easier to handle in practice.

Phil

From FORRERJ@frl.orst.edu Tue Aug 22 17:32:02 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id RAA27345 for <hfsig@tapr.org>; Tue, 22 Aug 1995 17:31:56 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id PAA18932 for <hfsig@tapr.org>; Tue, 22 Aug 1995 15:31:51 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21);
    22 Aug 95 15:38:36 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 22 Aug 95 15:38:27 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 22 Aug 1995 15:38:26 PST8PDT
Subject:       Re: [HFSIG:543] Re: Robust modems
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <196BA07F41@frl.orst.edu>

Hi Phil,

Just a question out of curiosity. I gather that the STA for SS does not 
allow for the usage of simultaneous P-N sequences and frequency 
hopping schemes. Without this means of SS, would it be technically possible 
then to solve the near-far problem for amateur communications?

--Johan 
From karn@qualcomm.com Tue Aug 22 23:07:36 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id XAA30575 for <hfsig@tapr.org>; Tue, 22 Aug 1995 23:07:33 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5) id VAA16765; Tue, 22 Aug 1995 21:07:31 -0700
Date: Tue, 22 Aug 1995 21:07:31 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508230407.VAA16765@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <196BA07F41@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:544] Re: Robust modems

Near-far is a potential problem for all spread spectrum systems,
regardless of spreading method. Frequency hopping does have the
advantage of making it easier to deal with hopping collisions through
coding, but there are techniques applicable to direct sequence as well.
IS-95 (which is direct sequence) is one example. Power control is
the key.

Phil

From chbrain@dircon.co.uk Wed Aug 23 14:22:05 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id OAA08068 for <hfsig@tapr.org>; Wed, 23 Aug 1995 14:21:58 -0500
Received: by felix.dircon.co.uk id AB16802
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Sat, 12 Aug 1995 06:53:21 +0100
Message-Id: <199508120553.AB16802@felix.dircon.co.uk>
Received: from ad029.pool.dircon.co.uk(193.128.231.29) by amnesiac via smap (V1.3)
	id sma016800; Sat Aug 12 06:53:12 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sat, 12 Aug 1995 05:46:30 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:532] Re: Robust modems


>
>CCW is a form of coherent demodulation/detection. 
>
>--Johan, KC7WW 
>
>
Hello,
 From my memory the CCW filters I have seen described in the past have used
Quadrature matched filters which according to my understanding of the book :

Communication Systems 3/e by Simon Haykin ISBN 0-471-30584-7 published
by Wiley, are designed for non-coherent reception.

I guess this means that the phase in CCW is not necessary to know just the 
QRG and the start and end of the integration period ?

Back to this 8ary FSK modem I am still investigating, well I spoke to a guy at
Leeds University here in the U.K who works in the H.F radio research dept and
he advised me that I should be using matched filters for my 8ary modem. 

So this CCW discussion ties in nicely with what I am now looking at. At least
rectangular pulses are the simplest matched filter to build.


Regards

Charles 

(QTH somewhere on the learning curve!) 
-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From chbrain@dircon.co.uk Wed Aug 23 15:38:34 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id PAA09292 for <hfsig@tapr.org>; Wed, 23 Aug 1995 15:38:12 -0500
Received: by felix.dircon.co.uk id AA17468
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Wed, 23 Aug 1995 21:37:56 +0100
Message-Id: <199508232037.AA17468@felix.dircon.co.uk>
Received: from ad004.pool.dircon.co.uk(193.128.231.4) by amnesiac via smap (V1.3)
	id sma017461; Wed Aug 23 21:37:52 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 23 Aug 1995 20:36:09 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:546] Re: Robust modems

>
>>
>>CCW is a form of coherent demodulation/detection. 
>>
>>--Johan, KC7WW 
>>
>>
>Hello,
> From my memory the CCW filters I have seen described in the past have used
>Quadrature matched filters which according to my understanding of the book :

Wow,
 I sent that message about 1 week ago, like a lot of things after re-reading the
books I regretted sending the message! Still I can't see why it took so long
to be
reflected back from the list server.

I am still playing with the matched filters. Still things have advanced at
this end
as I am now using PC-DSP Professional and PC-SIM which allows me to mock up the
modem before committing it to DSP code.

It has a few bugs in it but appears good value for money at $200 rather than the
$2000 + for matlab!

Hope you all enjoy the DCC I am looking forward to reading the conference notes.
I have just finished reading the proceedings of HF95 that took place in
Sweden last
week.

Regards Charles

From sadowskp@usafcrqs.nellis.af.mil Thu Aug 24 11:32:08 1995
Received: from bncc.nellis.af.mil (bncc.nellis.af.mil [132.58.120.19]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id LAA21071 for <hfsig@tapr.org>; Thu, 24 Aug 1995 11:31:59 -0500
Received: from mailgtwy.nellis.af.mil by bncc.nellis.af.mil with SMTP
	(1.38.193.4/16.2) id AA04993; Thu, 24 Aug 1995 09:31:28 -0700
Received: by mailgtwy.nellis.af.mil with Microsoft Mail
	id <303C81F2@mailgtwy.nellis.af.mil>; Thu, 24 Aug 95 08:43:14 cdt
From: "Sadowski,P CPT USAF CRQS/RQEN" <sadowskp@usafcrqs.nellis.af.mil>
To: hfsig <hfsig@tapr.org>
Subject: RE: [HFSIG:547] Re: Robust modems
Date: Thu, 24 Aug 95 08:48:00 cdt
Message-Id: <303C81F2@mailgtwy.nellis.af.mil>
Encoding: 20 TEXT
X-Mailer: Microsoft Mail V3.0


Please, more info on these two packages

Thanks in advance

Al   AH6LS
sadowskp@usafcrqs.nellis.af.mil
 ----------
>From: hfsig
>To: hfsig
>Subject: [HFSIG:547] Re: Robust modems
>Date: Wednesday, August 23, 1995 3:50PM

> PC-DSP Professional and PC-SIM

> appears good value for money at $200 rather than
>  the  $2000 + for matlab!

>  Regards Charles

From chbrain@dircon.co.uk Thu Aug 24 12:41:57 1995
Received: from felix.dircon.co.uk (felix.dircon.co.uk [193.128.224.10]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id MAA21986 for <hfsig@tapr.org>; Thu, 24 Aug 1995 12:41:44 -0500
Received: by felix.dircon.co.uk id AA04264
  (5.67b/IDA-1.5 for <hfsig@tapr.org>); Thu, 24 Aug 1995 18:41:33 +0100
Message-Id: <199508241741.AA04264@felix.dircon.co.uk>
Received: from ac035.pool.dircon.co.uk(193.128.230.35) by amnesiac via smap (V1.3)
	id sma004231; Thu Aug 24 18:40:59 1995
X-Sender: chbrain@dircon.co.uk
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 24 Aug 1995 17:39:07 +0100
To: hfsig@tapr.org
From: chbrain@dircon.co.uk (Charles Brain)
Subject: Re: [HFSIG:548] Re: Robust modems

>
>Please, more info on these two packages
>
>Thanks in advance
>
>Al   AH6LS
>sadowskp@usafcrqs.nellis.af.mil
> ----------
>>From: hfsig
>>To: hfsig
>>Subject: [HFSIG:547] Re: Robust modems
>>Date: Wednesday, August 23, 1995 3:50PM
>
>> PC-DSP Professional and PC-SIM
>
>> appears good value for money at $200 rather than
>>  the  $2000 + for matlab!
>
>>  Regards Charles
>
>
Well here are the facts, I appologise for the advert at the end but I have
had a number
of requests for information about the package.

Hello,
 I hope this is of interest to you! It has some bugs in it but you can
design filters with it, play with FFTs and
most other DSP functions. With the PC-SIM I have emulated an 8ary FSK modem.
I am also going to 
emulate an H.F channel simulator with it, the output can be displayed or
imported into Excell. I ordered it via 
the internet and it arrived in about 1 week, it fitted in a paddy bag. You
get the disks and a large manual.

                      PC-DSP Professional Edition
                      ---------------------------

  The professional edition of PC-DSP is available from DSP Solutions, and
  provides a significant number of enhancements over the student edition.
  Site licenses are available for educational institutions.  In addition,
  students with a valid student ID may upgrade to the professional edition
  at a discounted price.  For ordering information, please see the file
  'ORDER.FRM'.  For site license information, see the file 'SITELICE.TXT'.

  Following is a partial list of enhancements in the professional edition
  of PC-DSP:

  * Protected mode support.  Works with 286 or better.  For most operations,
    discrete sequences can be as long as permitted by available memory and
    disk space.  In the student edition, discrete sequences are limited to
    1024 samples.

  * Graphs are customizable in terms of titles, labels, and colors.  Support
    is provided for converting graphs to several popular formats including
    postscript, HPGL, and Latex picture formats.  This allows professional-
    quality printer plots to be obtained.

  * Increased limits in filter design, analysis, and simulation.  In the
    student edition, FIR filters are limited to 55 taps, and IIR filters
    are limited to order 10.  The professional edition raises these limits
    to 256 and 50 respectively.

  * Automatic code generation for IIR and FIR filters.  Assembly language
    code for designed filters can be automatically generated for Motorola
    DSP56001 and Texas Instruments TMS320C30 processors.  In addition,
    standard C code can also be generated.

  * Increased limits for model orders in autoregressive (AR), moving
    average (MA), and autoregressive moving average (ARMA) spectral
    analysis.  In the student edition, the model order is limited to 20.

  * Includes the macro compiler.  Using the macro compiler, a set of PC-DSP
    commands can be compiled into a macro file which can be executed with
    the 'Run macro' menu choice.  This feature makes it possible for the
    user to add new functions to PC-DSP by combining the existing functions
    in a certain way. Also, by using disk file input-output functions, it
    is possible to interface stand-alone executable programs to PC-DSP, and
    make them part of an integrated environment.  Full documentation on
    PC-DSP macro language is also included.

  * Includes the dialog compiler.  Using the dialog compiler, interactive
    data entry forms can be developed as front ends to PC-DSP macros.
    These data entry forms have the same general characteristics as the data
    entry forms used in PC-DSP user interface shell.  Full documentation on
    PC-DSP dialog language is also included.

  * A number of macros are included covering advanced topics such as
    adaptive filtering and wavelet transforms.  Additionally, a macro is
    provided for importing and exporting sound files in WAV format.

  * Source code for reading and writing the binary data files used by
    PC-DSP is provided to aid in the development of child processes
    (external executable programs that are executed from within a macro).
    Languages supported are: C, Pascal, Fortran, and QuickBasic.


                        Other Related Products
                        ----------------------


  This file contains brief descriptions of related products by DSP Solutions.
  For ordering information, please see the file 'ORDER.FRM'.  For site
  license information, see the file 'SITELICE.TXT'.



  PC-SIM
  --------------------

  PC-SIM is a continuous- and discrete-time simulator that is used for
  time-domain simulation of systems described by block diagrams.  It was
  designed to be a flexible and open-ended tool to allow simulation of a
  broad range of systems encountered in communications, signal processing,
  and controls.  The block diagram under consideration may contain linear
  and nonlinear components.  Continuous- and discrete-time components can
  be mixed within the same block diagram through the use of impulse
  samplers coupled with continuous-to-discrete and discrete-to-continuous
  converters, and zero- and first-order hold devices.  Multiple samplers
  can be used with different sampling rates and/or non-synchronized timing.

  PC-SIM is fully compatible with PC-DSP in terms of the data file formats
  used.  For example, a sequence generated in PC-DSP can be used as input
  to a system to be simulated using PC-SIM.  The output signal obtained
  from this simulation can be brought into PC-DSP for FFT analysis.  A
  filter (analog or digital) designed using PC-DSP can be used as one block
  in a block diagram to be simulated using PC-SIM.

  A block diagram is described to the program using a very simple script
  language.  Simulation models for a wide variety of linear and nonlinear
  component types have been developed for use in systems to be simulated.
  Following is a partial list of available component types:

        Input port (ASCII and PC-DSP files)   Sin(x)
        Recorder   (  "    "    "      "  )   Cos(x)
        Adder                                 Tan(x)
        Multiplier                            ArcSin(x)
        Amplifier                             ArcCos(x)
        Dead zone                             ArcTan(x)
        Comparator                            Sinh(x)
        Comparator w/ dead zone               Cosh(x)
        Comparator w/ hysteresis              Tanh(x)
        Limiter                               ArcSinh(x)
        Limiter w/ dead zone                  ArcCosh(x)
        Limiter w/ hysteresis                 ArcTanh(x)
        Compressor (u-law and A-law)          Exp(x)
        Expander   (  "    "    "  )          Log(x)
        Full-wave rectifier                   Log10(x)
        Half-wave rectifier                   Square
        Zero-order hold                       Square-root
        First-order hold                      Reciprocate
        Sampler (Impulse sampling)            Minimum
        Continuous-to-discrete                Maximum
        Discrete-to-continuous                Sine Oscillator
        Continuous linear system { G(s) }     Cosine Oscillator
        Discrete linear system { H(z) }       Pulse Oscillator
        Integrator                            Triangular Oscillator
        Differentiator                        Unit-Step Generator
        Shifter                               Unit-Impulse Generator
        Quantizer                             Gaussian Noise
        Multiplexer                           Uniform Noise
        Demultiplexer                         Volt. Cont. Oscillator
        FIR digital filter (from PC-DSP)      Down-Sampler
        IIR digital filter (from PC-DSP)      Up-Sampler
        Analog filter (from PC-DSP)           Adaptive LMS filter

  In addition, well-commented C language source code can be automatically
  generated for the block diagram described.  This allows the development
  of stand-alone executables to simulate particular systems, and can also
  be used for porting a system to run on a DSP processor.



  PC-DSP FOR WINDOWS
  --------------------

  Has the same features as in the PC-DSP professional edition, except it
  works within the Microsoft Windows environment (version 3.1 or higher).
  Tightly integrates with PC-SIM for Windows, but can be used without it
  as well.  Available April 1994.



  PC-SIM FOR WINDOWS
  --------------------
  Has the same features as in the DOS version of PC-SIM described above,
  except it works within the Microsoft Windows environment (version 3.1
  or higher).  It also allows interactive drawing of the block diagram on
  the screen.  Once the block diagram is drawn, the system description file
  is automatically generated, and the simulation is run.  Tightly
  integrates with PC-DSP for Windows, but can be used without it as well.
  Available April 1994.



  DSP LIBRARY
  --------------------

  Extensive C language library of signal processing functions in source
  code format.  Functions cover a broad range of operations including
  binary file operations, waveform synthesis, elementary signal operations,
  signal statistics, convolution, correlation, FFT analysis, filter design
  and implementation.  Most of these functions were used in PC-DSP.

  Royalty-free right is granted for the distribution of straight application
  programs (in executable format) developed using these functions.  Contact
  DSP Solutions for a list of functions and pricing information.

                            ORDER FORM

DSP Solutions                              e-mail: pcdsp@minuet.siue.edu
P.O.Box 341                                        DspSol@aol.com
Glen Carbon, IL 62034
________________________________________________________________________

PRODUCT                  QUANTITY        UNIT PRICE      AMOUNT

PC-DSP Professional      ______          $ 99.00         $______
Edition

PC-DSP Professional      ______          $ 59.00         $______    (*)
Editon (w/ student ID)

PC-DSP for Windows       ______          $ 99.00         $______
(Available April 1994)

PC-SIM for DOS           ______          $ 99.00         $______

PC-SIM for DOS           ______          $ 59.00         $______    (*)
(w/ student ID)

PC-SIM for Windows       ______          $129.00         $______
(Available April 1994)

Bundle-1                 ______          $159.00         $______
PC-DSP Prof. Ed. &
PC_SIM for DOS

Bundle-2                   1             $199.00         $______
PC-DSP for Windows &
PC_SIM for Windows
(Available April 1994)
                                              Subtotal  $ ______

          Illinois residents must add 6.25 % sales tax  $ ______

Disk format    [3.5"]  5.25"                   Shipping  $  10.00
(circle one)
                                                 TOTAL  $     (**)

 (*) Please include a photocopy of your student ID.
(**) Personal checks, Visa, MasterCard.
     Purchase orders accepted from academic institutions.
________________________________________________________________________

   Name: __________            Company: _______________________

   Address: __________

   City: __________              State: ___________  Zip :___________

________________________________________________________________________

CREDIT CARD INFORMATION               Circle one:    Visa   [MasterCard]

   Name on card: _______________      Account Number: __________________

Expiration date: _____                Signature: _________________


-- -----------------------------------------------------------------
  "projects don't slip, they just catch up with reality" 
 
  Charles Brain (G4GUO)           
  Chelmsford, Essex.                   
  E-mail chbrain@dircon.co.uk  
  POTS +44 (0)1245 353221     
  FAX  +44 (0)1245 275448     
-------------------------------------------------------------------

From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:34:52 1995
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id KAA00475 for <hfsig@tapr.org>; Mon, 28 Aug 1995 10:34:37 -0500
Received: from ntcite01es.ntc.nokia.com (ms-smtp-gw.tele.nokia.fi [131.228.138.80]) by axl01it.ntc.nokia.com (8.6.9/8.6.9) with SMTP id MAA12997 for <hfsig@tapr.org>; Mon, 28 Aug 1995 12:21:56 +0300
Received: by ntcite01es.ntc.nokia.com with Microsoft Mail
	id <30419971@ntcite01es.ntc.nokia.com>; Mon, 28 Aug 95 12:24:49 eet
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>
Subject: Re: Various comments on the newqpsk
Date: Mon, 28 Aug 95 12:06:00 eet
Message-ID: <30419971@ntcite01es.ntc.nokia.com>
Encoding: 210 TEXT
X-Mailer: Microsoft Mail V3.0


>From: Pawel Jalocha

>We should take few our latest talks and send them to HFSIG
>- who will do that ? :-)

Well, now I did it. Blame me, if you find your texts published ;-)

>> Do you think that 50 mV could get distorted in the (FT757GX)
>> mic preamp?
>
>I looked at the diagram and there are two transistors with a fancy
>loopback before it comes to the potentiometer.
>In principle 50 mV could be distorted there already... not much,
>but I think a bipolar transistor does show some non-linearity
>at the 50 mV level.

Maybe Joni and I shoud try even lower input levels? I think that would at 
least
sort that alternative out.

>The MIC socket: On my diagram, there is no AF output on the MIC socket...
>The audio-in on the read is actually the same as on the MIC socket.

This is what I remembered, too. I have now found the extra mic plug I had
so I will solder it in during this week. I will solder the up and down 
switches
to this plug so that we can test the rig autotuning. This will be very 
interesting!

>I measured my transmitter passband today... I connected a simple
>RF-voltmeter to the TRX output. Here are the output amplitudes:

I plotted this, too. Did you have the mic connected when testing? As the mic 
is
in parallell with the AFSK input, it influences the response very much. The
output seems lowpass filtered, and by far not as nice as Jonis' TX. The 
excel
sheet is in the end of this message as uue. Joni's plot is in the same file 
so you
can compare the results.

>The more I think on the problem the more I am conviced that this is
>a REAL problem in all type of multi-tone modems (including picollo 
systems).
>I am pretty sure that this is the problem seen now but Joni and Timo.

>Here are two issues:
>1. Same as for auto-FEC/Interleave setting: the stations needs IDs
>   known to the TNC and every station should be treated separetely.
>2. The modem doesn't "see" what on the air directly but through the
>   receover filters, thus the measurement of the carrier's amplitudes
>   will be seriously affected.

Well, how about adding a learn code in the beginning of every transmission,
every station could then retune the receiver for each received packet. There 

would be no need for TX recognition as it would be done every time.

>I like more the idea to measure my transmitter and hardwire the correction.
>This should fix the thing once and for all.

This works well with one rig, but what if there is no common characteristic
for the diffrerent transmitters, as it seems?  A software that would take 
the
results from TXtest and convert them to weights for the different tones in
NEWQPSK.DAT? That might be a simple solution for the user.

Here is the new XLS file.

73, Timo
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Hello,

I came home last night at 22  o'clock so I did not have time to make the TX 
test yet. I
think I'll do it tonight.

I made the RX test this morning before leaving to the job. I made it in the 
same manner as
Pawel: I switched the marker generator on and tuned the rig around the 
marking frequency.
If I do not recall wrong, the S meter measures the input _voltage_  so that 
one S-unit is 6 dB.
In order to find the half power bandwidth one needs to find the edges where 
the voltage drops 6dB
ftom the passband peak, i.e the power drops 3 dB.

Well, the result was very simple. the -6 dB voltage points were exactly 3,5 
kHz apart. There
was some ripple in the passband, but it was not more than 1 dB (= the 
thickness of the needle).

I'll be back with the TX results when I get the tests made.

My rig is an FT757GX MK I

73, Timo
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 ----------
From: Pawel Jalocha
To: danie.brynard; Johan Forrer; Timo Sivula; Frode Weierud; Jarkko Vuori; 
Joni
Subject: Re: Various comments on the newqpsk
Date:  25. August 1995 23:39

Hello everybody,

> First: Should we either move this discussion to the hfsig group, or create 
a
> new group
> for DSP56k qpsk testing and reporting? I suggest this, as I am getting fed
> up with this
> carbon copying every time :-)

In principle I could create a simple mailing list on home-gate
but HFSIG is a better place maybe.
We should take few our latest talks and send them to HFSIG
 - who will do that ? :-)

> How does the headphone output relate to the line output? At least the
> headphone
> output is quite noisy.

I would expect same amount of noise on the line output.
The "ideal" solution is to use a resistor divider just before
the microphone input.

> Do you think that 50 mV could get distorted in the
> mic preamp?

I looked at the diagram and there are two transistors with a fancy
loopback before it comes to the potentiometer.
In principle 50 mV could be distorted there already... not much,
but I think a bipolar transistor does show some non-linearity
at the 50 mV level.

> This seems like a good idea, the only problem is that as far as I remember
> Joni
> reduced the output power until it could not get less, and it still worked
> ok. The 757
> has quite good dymaics in what comes to setting the TX output. Remember 
that
> we are only 10 km apart.

Your antennas are too good - cut them by half :-)

The MIC socket: On my diagram, there is no AF output on the MIC socket...
The audio-in on the read is actually the same as on the MIC socket.

> Sorry, no. T4 runs on a TheFirmware TNC, and I have to use a KISS emulator
> (TFKISS) to interface T4 to an non TF TNC.

I always thought software is so much flexible :-)

> Why not make this automatic instead? Let the modem collect the number of
> errorcorrections and then according to some trig-levels switch automaticly
> to a less complicated FEC and higher speed if the link permits it, and 
vice
> versa.
> You only need to find out how to tell the other modem about the mode
> change... ;-)
> but with 15 tones to choose from that should not be too difficult, I hope.
>
> Now the modem would autotune and fit the errorcorrecting code according to
> the
> band conditions, what say?

In one-to-one QSO this is "easy" but if we want to keep this modem
compatible with the ideas of packet network the whole issue becomes
difficult. You are going to send packet to two or three station
and for every station you may need to use different parameters.
Thus you need to give every station an ID which is known to the TNC
(KISS TNC doesn't know anything about callsigns).
Then, the TNC would need to gather statistics for every ID separately
and then decide and agree with the other station upon the parameters.
Phil's new protocol probably does something like this...

> Here came the Problems. I pressed w once, and the hard disk started 
running.
> And it did not stop, not until I forced the system down with ctrl-alt del.

Definetely a wrong behaviour but why I can't say... maybe Jarkko ?

> What does the S do? What happens when I press w, or what should
> happen?
> How does this SPY work?

When you press "S" the PC sends the request (just the character "s")
to the DSP to send the "spied data". The programmer (that is me) decides
what are the "spied data" at the moment.
In response the DSP sends "P" and then 512 16-bit words.
This words are being displayed in a form of diagram on the screen.
They can be for example the FFT values, or just the input samples,
or samples after a filter - anything: it's up to the programmer.

When you press "w" the SPY.EXE should write those 512 words onto an ASCII
file - that's all. Why this simple thing did not work, I don't really know.

> I will be out of town for the weekend but this test seems to be a good 
one.
> I'll
> run it when I get back on monday. Could you make the test soft so that one
> could give the modulating tone directly as a number? Like 100 (enter) 
would
> give 100 Hz,  3000 (enter) would give 3 kHz? This would be very useful for
> other applications as well... A settable sinewave generator on the DSP4!

Well, you can make it multi-tone, multi-waveform, etc. :-)
But for now it has to wait... or there is maybe a voluntier
to take this job ?

I measured my transmitter passband today... I connected a simple
RF-voltmeter to the TRX output. Here are the output amplitudes:

Carrier    Amplitude
number        [V]

 1            14.3
 2            14.2
 3            14.1
 4            13.7
 5            13.0
 6            12.1
 7            11.5
 8            11.2
 9            11.3
10            11.1
11            10.7
12            10.5
13            10.6
14            10.5
15             9.7

The difference between first and last is about 1.5 which make more
than 2 in the power level.

The more I think on the problem the more I am conviced that this is
a REAL problem in all type of multi-tone modems (including picollo systems).
I am pretty sure that this is the problem seen now but Joni and Timo.

What shall we do about it ? I can see two "main" solutions:
1. Make the transmition so narrow that it fits into "every" transceiver.
   But then your bit rates will be so low... or you will not be able to take
   those _real_ advantages of multi-tone transmitions. And when you make
   the transmition significantly narrower than the SSB passband you get
   additional problems with the AGC of the receiver, the anti-aliasing
   filters, etc. The whole excitement falls apart...
2. Stay with about 2 kHz bandwidth and let every operator adjust the 
passband
   center and carrier level correction. Thus keep higher bit rate and take
   some advantage of spreading the signal over larger bandwidth.

> Pawel, excuse me for my mad ideas but... Could this be done?
>
> Make one of the preamble tones being in the high end of the pass band. 
Like
> 1500
> and, or why not using 3 or more tones.
>
> The receiving modem, during tune phase, measures the level difference
> between this
> tone and a tone in the "flat" response area. The dummy bits (pre/post data
> or whatever
> they are called) is then used to send the measurement data in the next
> transmission
> back to the other end.

Here are two issues:
1. Same as for auto-FEC/Interleave setting: the stations needs IDs
   known to the TNC and every station should be treated separetely.
2. The modem doesn't "see" what on the air directly but through the
   receover filters, thus the measurement of the carrier's amplitudes
   will be seriously affected.

I like more the idea to measure my transmitter and hardwire the correction.
This should fix the thing once and for all.

> How about automating this, too like above? Is it possible? How much
> processing power
> would this correcting need if it would be done "live"? This feature could
> also help against
> selective fading in some cases on HF.

This might be indeed very interresting but is selective fading
"stable" enough ? I suspect the "notching point" moves all the time...

Pawel
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Hello,

I plotted Jonis TX response with Excel, so those of you having Excel 5.0 can 
view
Jonis TX output response. I plotted it against frequency and calculated the 
output
mean voltage from the mesured power assuming a load of 50+j0 Ohm

 P=U^2/Z
 U= SQRT(P/50),

Peak voltage would be U= SQRT(2) * U, if somebody wants to plot that, too.

There are 4 plots in the file, voltage vs freq, power vs freq and two dB 
plots.
The dB vs freq is calculated with the lowest measured level as reference ->

dB = 10 log (P/4,6). I plotted this in two ways in order to make it as easy 
as
possible to use the results for correcting the modem output. The output 
seems
quite nice, I think. It is within  1,2 dB within the whole passband. This 
should not
affect the quality of transmission. Would my loudspeakers do this from 20 to 
20000 Hz
I would call them dreamware ;-)

I'll be back with pictures of my own rig when I get the rig measured.

Please let me know If you would like the plots in EXCEL4 instead? I do not 
have LINUX,
so this is what I have to offer...

73, Timo

begin 644 plot.zip
M4$L#!!0````(`+Q4'!\.;(S.D10```!F```*````5%A415-4+EA,4^U="W04
M59J^5=V=?B0A'=*=\$PJ`4((G9!7$S@JC\C+'9X"0UQ@&(0&LI)T2(*.R*S1
M">HL/E!T]I`116=UF'78#3KNPV5F\,AF1M<Y.'/.+KL>6'!T=?:L1U'9,S@J
MO?__W[JW'MT5\L)A38IS4]7?_[BW;MW__O?_JZZ^<3+[W%-'Q[S%;,<US,4N
M)?PLS80I>J$CR)BJ_[Z42"0$G!@^_E\=7T"YI!>W_BSQF7OY(V9^*`$HZ5`R
MH&1"&0$E"XH'2C:4D5!RH(2@A*'D0LF#,@K*:"ACH(R%,@[*>"CY4`KTN@KA
M7`1E*I2)4"9!*88R&4H)E"E02J%H4")0RJ"40YD&I0)*I:YG^.C?<2.+P[\V
MZ-_YK`G.+>QVUI<C%T:!T(7S0="G$GZ<DQ>8>>]9MW)-U<Z7%!=<M^M8'=5_
M"^OO$8!9R'P_O9'QX3B*BCGM>JB_D36S9>QF]F>LK\=(IBHX![KTN:^W<M_0
MSQZVDNV$^AO91NK[&^`I;($6M1#2QAK@NJD'/27]N/\)4$X4,3FG#]O/T#T4
M>/JN`!^[=MO%>7I)PZ:6>&M\2YLV_UN;8MNU:'F%MB;><DOKMEBLC58'=0U;
MMD3))Q!'^4JDE$=[N8ZX!",6ZS^WY\F//UVV+?C<PSXV=?(+_X%T.U8!V*-%
MW">AWUG.^!KD=X7<_GQ`0Q\VKHC[I@HX8[WSBKB/VE[$_51'$:__?C@OA/.^
M0G[_I(,UYB\8^6^+%:S%=3B(GJZ&,=W;^55QI:AH;%B;6\FDLZJH1,E0S[!F
MFN/R"9^L)!*(IY,LQPT-AE;!Z\R!/CG7C=H5:#_^^EP5?8K298IHFT#,;<-9
M[P^J\12XA$(2(16],%[E0.N+''A5ZOGQ:87L/#M#/5ADTQ+1>R<'KB:DD%(`
MC23572>EZAREZI*DZJ54O:-4?9)4DY1J<I1J2I+JD%(=CE(=25*=4JK34:HS
M2:I+2G4Y2G4E275+J6Y'J>XDJ=/,<M0$C3(I.(:I*C?39V%,+H;S:A@7NP&Z
MBU4#Q[)@",S/&"6?ZDN[XB`.MA5!G[3RS"`N\_+_)-[4T*JMJM>^'M_>MG%K
M3+NU55O0$MNQ,]:TZ79M<C!-YQ=-X"O/?)HM'LEPJ2/,;6V^=PXBBH'4[R7$
M-&SG/$2(RT`>?9@0MX'<MY\0CX'L?HP0TXS5_)>$>`UD\P%"?*;:OT^(WT`6
M'R0D8&K/DX2D&TCG(4(R3"U\BI!,`WGP:4),=W_?#PC)HA]OO+1Q]KF""D*"
M/#1[8?VKWUS(D>PDGI&$%/S\TA>??3B-D)PDGA`AQ>_?L#Q[*><)$S+YXWTW
M-#W)D=PDJ;PDS:,(>7/ILJ/_^5DY(:,)&;_AO<5G5G%D3)+FL81,Z=QV9H^W
MDI!QA.0\W?W*1Q&.C+?4CGV\GLVB9^^!YYV;YF6?N-*@1=B38;UE]`CF*LH<
M&I@^%KGU5.:J5Q/4U>M*3V7Z??`\/1J,M=>\(="B%L\-`YMW.8[5XN7?(?4=
M]/<I"EI0#_Y+H\KX<6ZV<:X&7A<N$6FAK`)G'OY5E2`B:C`HF]7U>J&R[T`W
MV=4A&)ZHU046A.<L^(>XV:)6!,?KTWR878.KOH<R-\SRD#XT224+&50S`SFN
MH&QS5AIH$_A\:@^:W+R@"P?L@B`V=FX0Q\JOH,H:,*$/8&C_([3`;/I3@?8C
MD'T?9*Z#83V>).P'2FCZS2AZ1<AILET39T&P-(6.U$>!8I^JFN`YO`M/]#GT
M3HY354B/4'&J\MJF*IP)U$6[<#IRR>G(7,46%(2YX`2<3T'YKIJJBCQ]D9*J
M"IQ^E#58@RIKB$*I(HJ+FNP-!EA[>[L(<X(9[.VWWY;+)Y0(!4-)'2(Z<10]
MT:*@,?EDL8E!;)_Y3DXD$GS,>VC,8Q+H96K2S_55X&_1,B`V#*S:%J-E7ZQ%
M2W74@=0[[L?A+UJXRN,BR@K@W^MHSODF^_&T<6-FZ+=0K\XAV@/TMXC^CB`3
M>9.N*^$9_1)CJCOW\;;N\LQM:=BXG>,*X,?49%QUX'<Y\*?6?\@1=ZHW&<]W
MCX.9:/2$R(0)%>NTHL9;BJY95V;ZE>\NA&DCWTQ?>V-L\WH;4Q&,G0)"RBML
M>B20[YX,L]1$&Y=9FXGU6LBFS-Q05JJ9JME0!CKM"/(4E169?L_94(;R4RSR
M&QHWW&*5UQ$I+W^3_#Q8_\V5\K)A9A5F4-<R>[:]'?,@8V338V^*&33I,;?G
MG.XQ_S>AL>,:-Q3$%(Y=N!RF]A)C7R%,8=:^\L"3`+Z+5FQ*"BR2`BM-@?F3
M,!XQ:CZ![5?=+-CN2N`YNSV-SB/;W73.:??2&5),=`ZU>Q)[8!6@D(=.H_"T
M$H%GB@V@"H&#DPV@&H''2@R@!H$'IAA`%($]I08P'8%O3S6`6@1V1@Q@!@*-
M908P<P],>K%R"NYXPRH063_-A%0BLKK"A%0ALJ32A%0C,K_*A-0@<EVU"8DB
M$JTQ(=/1.W`'$"0'D*Z*1^QA)Z"[9F9@PA<GY0SXNQE\"%YGTQ`/PISS^8\^
M^LV2FY?/WD!X*>%3Z?INNFXW+9`GX2-A/N5^6MUL4>X"CI?=O5IF;5'XRF&!
MTM3&DI99;K::8<#Q;7T5O3J`Z^(%"E,#3)$Y:I_*1U$V-`&R#F&FO)*.F"JQ
MWWMI50B82V);\@3FEEA7/:Z\W&HVZ0O#:)4QS$_!R6%#PQ2>A"DD"5,8$J;0
M(TSA1IA"C#"%%6$*)<(4/H0I9`A3F!"FT"!,X4"80H`P+?NSH&+>:.PR"*6:
MX[?%6K!>E>I5YK0#I[*/_O+K<W<:UX?^'/6PD)W*$%>.[S:HVMWXM_ENG1/K
M'4D=DP7K0ZCW5A["I<%BW45K5+$4][&M,>4+#U,0/N8.`QFNLEQ9Z2R_BBW&
MA,;<$.-R*LB)8,6'C`E=CI-=%K4NYK:2W4`6P0:2/5:RQR:=9B6G`5D$.$CV
M6LE>((N8!,D^*]EG4^ZWDOVVI@6LY`"015"$Y'0K.1W((D)"<H:5G&%K6J:5
MG`ED$3LA>825C&&C"*20G&4E9]EN3!%DMYI#1I`%S=M<I[7%M9K(=&T-2KEI
M`,R]\<D59_UOS48I%:7<-``F`ME-`V`,RP^PQ9#P*]A"Q\@Y::/G,*5.:60>
MK@;'P[HC,UYY\&_?!C5NYKJDJ^%DEZ46-Q\/!AG'P]%KEE_(_)O31/98R1Z;
M=)J5C.,AJW3!_7<\]&LB>ZUD'`]UNZ=^GY6=(K+/2O;9E/NM9+^M:0$K&<?#
MB35G6_[J\"^(G&XEI^N1/G]WX>;CP2!GV)J6:27C>"@K&5/2.O8\D4=8R3@>
MUGSZVT/?_=I'1,ZRDK-L-Z8(\BFH=P7,KM?"2XMO0<2$X;="X;<*X;<"83V&
MWUXXATWI#7/X[=YY*C,X&.&WFRH;2/B][X`&31I`^+U&AM]\NAN\\+L!:+4P
M\2Z!\/LGMO`[`LWY,=#?`YF95T7X_1(\A__2P^\)5R;\W@KE+%3SSW".*SV%
MW^,=JL`\GAMSD%=%!)[X8<)X;7<T97^)`V\FS7(SV`H<2GA\D6"RW>)C#(7:
M;7[UDD[M6D\CS!_,2!S^8]9NT>^4?7Y=SSXGX+G=X3BFSO>0?49\K,P^+\<E
MDR7WW'/JN8L-IYY3IYY_]3H>(5/JN9J.L"GU;.;ALQ/W_B%3ZMG,PRVJ\P`>
M.:;4LSYSF%+/9JF\),VC3.W),:6>Q=K#2#V;-8\U2>694L^\/7FFU+.H7:2>
M7>3[/.3[,J&%%\CW38)S*M_7?/NIS*^_-BB^+U/OCO[Z/JUZ@*GGRA'"]_&5
MWN#YOHC*4\_'`\ZIY^/IETL]#Z:_R\=YB;F25=%G%874=NL,:)_-IGNO>((:
M/62&EWM(?X\>,MQ3%9OKKJ1_S`OB+/>]7OK(@7JI5'[E+I7[E2<"/?F568JS
M7\%<3XGT*RVQUN9X4VM,:VC2($+2UE96:-OC6TN63ZLIGSYE?<].Y@^CAYU,
M:B<CH@_#R8@0T7`R9AX^#8AHRW`R9AX^+$6X9S@9$4893L8LE9>DF3L9$;H9
M3D8<AI,Q:^9.1L1DAI,189CA9$3MPLFXR<EXP<GXX"O)/.C7$7`N=GB_>6'W
MJ<S7!L?)&%7T/\#2JG_1?R?3&+Q23F89T!9`QVZ%H9WG3PZPCKEX@!4)]#;`
MZLE)3+VBX==A,.K?Z<ZE\,HYEZ4^[EQ\5ZMSZ7WP=?6'/P$0^1J<]\*T^J#J
M]$QO`N8:!S>%>*63F[)Y*6U[0U-,:]X>;^O97S45#_NK87_5D[^:!>]?_BY-
M9"['0^_HW\A@:A&OG@,?HUWVX^/D=U3&P]D\^:IZ/T6CN-GN)N-;^?LI?!]E
M?`!+O2,KI]XQ/HX5IN9TW^M*AN9]KYHR-.][<>G0O.]Y4X?F?5\;&9KW75,V
M-.\[4CXT[WOBM*%YW^,JAN9]ARJ'YGUG5`W-^W97#\W[_GR(WO>%FJ_V?7\%
M_V,)N+<03WQOX5SV(352[!_C9Y=^]MKV*'(T4S^GZ^>`:0^BAZ76+_8N\IP>
ME^-9H/.@A^\^]-AV'Z;K]("N%67M>QPQ)S/1Y8&]W(M83,%R$:XOTF^QIQ'K
MQ\RB:*VHE>^(6P2\UOV=JKY;+D=%??SJHNEJF:0NDW7TU'*C#B[->3)TVD7(
M]0G:2AT[*[&S$NN66+?$CDCLB,3V2VR_Q'9);)?$-DILH\0626R1Q"Z:VL[[
M(*1^+K$+^A5BFR2V26*W2>PVB>V5V%Z)/2&Q)R3VO,2>EUBWQ+HE]J;$WI38
M!Q+[0&*J(C!5WD>NQ'(E-D5B4R1VG<2ND]@*B:V06$QB,:4O-I5AL8DR?72:
M]P/CZ#=LRLN\?;+9ONC?G+@S@>5*Z^=S@J)/C%;K'&&Q7G04]CG#.A,H-!-,
MHIG@`;8*1M9-[#[V#78/C,4]DH;7VP!K!%H+\-P&O(*&U[O90Y!M?P0X'@7J
M8Y2IG>3RTO4#4/:Q_4#9QP[`K\>A/`$EEWC\='T(Y'_`'F;/`.]AX/IK=I`=
M`1_5!>CS@`:)-XVN?\*>97\/YV-`>QDDNX%7T/'Z7T#^#:CM7T'GO[,'86P;
M;<7KLU#>`=I_0WT?0'V"AM>?P"[CBU#O%^R'T#='Y'W@]?#^^^']]W7#^^__
MB/OON=1I1ZG325*Y4BH7QF(JJ68E-\4(NU.7RH.K9"G:ZB(IAM1)*7724>ID
MDE2!(J0*4K202PF*(1674G%'J;@B+(^6KQ9_9/=#9GM,9<=YT+]"V_'CQZ%P
M.;?.C1C7@%=VB^:^1[%8J^`SV^0$:9.IG]82Q;!6PR8G2)MTDJI+DJJ74O6.
M4O5)4DU2JLE1JBE)JD-*=3A*=21)=4JI3D>ISB2I+BG5Y2C5E235+:6Z':6Z
MDZ1.2ZG3CE*GDZ3RI'6=26E=W?1QC-VZ\J1UG4EI75S*;EUYTKK.I+0N+F6W
MKCQI76=26A>7$I34]N0V68-A(5:_&(1?GZD?ZD'N,>G%:%LT6QKCFCPVSVM>
MN^&[]JJ`"SXZPE?%N*&B"-95&NW"X;;*OPSAFM)T38C9([?4-FI$?Z)OPDS5
MGT-8^E3K,]<8\EBE5%8HI0I32.6`G"HI0BI$>]-0*N105P$+,9=-R@4M$'.^
MYE"72U)$WYA[V3J/&?T\&O?&TK<DHZ`]$=AY[]<ITR2E'"AUK$I2YDO*/*#4
MPX=@@K)64OX4*$VP=A.4'9+2#)0.%I64>R7E'J!TLNF2<E!2'@=*%ZN5E!<D
MY7F@=+,9DO*JI/P2**?93$EQP>>>2)D(Y4X847/ARP]!>9HHF&0Z"90Z2&`)
MRL=$^364`O"JUYLH=0H]7W@.<:#,`PH?^R']JQ,^]A55+5IY>VM;K)%Y>XJ9
M/$FVE>RKK+:U3[':UJ;KN2;?96Q0C'Z_S5[,-AC61T`QW8O<*0%I,"\@`?CG
MI^*G;V60\RBMK6NC%80:N$)K\1FU41T78VL1S325%145?IV2HX^M8K)6L;DU
MP#!ZQ!HS@<>KZYW/7J3ZHA$<E1Y9WWSF43A>;<-7*U9^T5>Y^K@MIA2?L;75
M3_7BW;IH!Y_1PK40+V(+*Z='*JMJHE5^7:/U/M9"G*9S5=7.F.'(5:+TI&N4
M;CO%])62:>,EX^USZ_R\9.M:=^@MK(A$JT%KU*K33]$8<KU%XZLB,KTR6CDC
M9?MVZ.USTF0=GZDS=P&6:L66;LH.6J,FG+=18JS[/663^CA8Y>5R#_;X3CS;
MWF0F>Z<;,Q1]UQTD._S$P5Y56[;$;^.WV^W[I=:,ZV#D9[W*"RQ#^0>6I?P3
MRU9^RD)0<J&('`%>CP+:6.`9K[S(-%AG352>A5S8P7YEG`),9&ZN3,:I-_JM
M66Y_G^[#WX=ZID(]F:RMAY5.#=E8#F2;\*O*GO_[:'S6Y?;.Y\1T^IVFS\3<
M+CTI9FC/(-^AX9?Z\[Z@__HS!GG$I:['_'P"]'S.P[J#_IM$-9AGY?[K%*R4
MR'_51*(\^^K5N7\FN*,&]S.".VKGWBNXIQO<+8)[NIW[)L%=:W#/$=RU!O>7
MT4]?YG,(RGFQP]7ATN?1H)@7[WA$S'!^ZI$\9:%<BYC;@'GBOFG*5^),K%(&
MJNE[7%-5=,":?J:/I8&WZ5U]Y`R\32-H-5<U"/T4Y9H&H9_6<TTI^NG+L8_^
M^>G>U&/VD,GSU03E-S1++-KE[^-<T)<V#.1=\4#NT3H*]#62XR@X`NM[1-"E
MFMO0UU%P-?6,53^3;Y?-]9W7WXV)%:SYK4A/;S\&^TV)$14P>5BC`L6".D<%
MYLPKCP[>56XV10<LY7,5_6)O;ZJO$["]S/1U@O5-9&_>/Z7*-J5ZUR/R]\PQ
M?]^3U)D>W@A91X6X:VC57RPL6=ZY5RF8M;=[:?KQMFNV=;@ZWV,%L_[GP\2+
M16GP&@0N?0B^Q9`G7]_`!:O1MEAK&^X:VKF]K95V!K%9O_?FZ_]/B`6KM-IH
MK;:P7F,[$<-H>U5#8UQ;V7#KSNT;:5V+;9Q:!E$F[#=B.H9E55QKC$6TMFVP
MZFV-Q1I;M1T[&]IBVM9X?'.YSA-,_F^0R_U#V"7ON+^2G^5\:<?_`5!+`0(4
M`!0````(`+Q4'!\.;(S.D10```!F```*````````````(`````````!46%1%
<4U0N6$Q34$L%!@`````!``$`.````+D4````````
`
end
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From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>
Subject: Resume of multitone discussion.
Date: Mon, 28 Aug 95 11:17:00 eet
Message-ID: <30418B59@ntcite01es.ntc.nokia.com>
Encoding: 24 TEXT
X-Mailer: Microsoft Mail V3.0


Hello all,

we (Pawel, Jarkko, Johan, Frode, Joni, Danie and me, Timo) have been 
carrying
out some practical discussions during the on-air testing of pawels 
multi-tone
modem. Now when Pawel has made a well working version of the modem the
discussion has turned more to a discussion covering general aspects of this
mode.

I think that it would be very good if everybody on this list could catch up 
with the
discussion and also join in. I will forward some of the latest mails to the 
hfsig list.
I hope that the guys in the test-group would also move the discussion to 
hfsig,
because I  personally am getting fed-up with the carbon copying ;-)

If you get fed up with this DSP4 related stuff, don't hesitate to ask us to 
get back
in to the silence ;-)

73, Timo OH6KK/OH2LVZ
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 ----------
From: Pawel Jalocha
To: Joni; Timo Sivula
Subject: A test to resolve passband problems
Date:  24. August 1995 13:41

To resolve what is the problem with the amount of errors on Timo's side
I suggest the following experiment:

Joni would send regular beacons (a rather long ones - 100-200 bytes).

Timo will do the following:
 - compile the source with SPY=1 and SPY_RxCrossedIQ=1
 - disconnect the PTT and MIC lines from the tranceiver
  because with SPY=1 the modem transmits random data packets.
 - load the .LOD file into the his DSPCARD4
 - start the SPY.EXE (supplied with the DSPCARD4 tools) like this:
  spy -p2  (-p2 means the DSPCARD4 is on the COM2)
 - press "s" when Joni's beacon comes and the red LED flickers.
  After a moment Timo will get some funny data displayed on his screen.
 - press "w" to save this data into a log.dat file.
 - e-mail this file to me ! :-)

The data there will be the real and imaginary parts of the differential
phase decoder output for every carrier. The plot will have the periodicity
of 30 because there are 15 carriers and 2 values/carrier.
You can see there how much the carrier amplitudes vary and how clean
the output is: for no-noise output the imaginary part (the second number)
should be zero. I hope to find out this way whether the problem concentrates
around the edge carriers or maybe it is spread all over the band.

Pawel
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From: Pawel Jalocha
To: Danie Brynard; Frode Weierud; Timo Sivula; Johan Forrer
Subject: A piece of my discussion with Joni
Date:  24. August 1995 23:09

Just a piece of my discussion with Joni, I thought it could be interresting.

> > Does your NOS behave the same ?
> >
> Sorry to say but yes. We must do first some coding to get this one work.

Maybe at least Timo's T4 can issue KISS commands ?
I found a partial way around this problem in JONS - you type:

comm tnc "\300\10\1\300" (this command sends a given string to a given
                          interface)

In this example I send the following characters:

C0hex, 8, 1, C0hex and the comm adds CR (13) by itself.

C0hex is the "new packet" flag in KISS protocol so after all I send a 
complete
packet saying: set parameter 8 to value 1.

The problems are:
1. I cannot send a zero because a zero byte is the end-of-string marker.
   Thus I cannot set the FEC nor the Interleave to zero !
2. The "comm" adds the CR by itself thus infact I start a new packet
   and put one byte into it... this makes problem sometimes and the first
   good packet which follows is not accepted.

> Yep, but it works well with FEC 3 and we tested this spy thing you
> tols us to do, Timo had problems with his spy and it made 8 MB files on
> hid HD ;-)... user error who knows ;-)

This is very funny... for me the SPY makes a file of 512 lines and there is
one decimal number in every line. I never had problems with that.

> > You could try to set transceivers to some low power (5-10W) with FEC=3
> > and then ask somebody to put a dead carrier on the channel
> > - the packets should still be received !
> >
> Yes this test we MUST do ... very very intresting one.

The result maybe mixed because already some carriers seems
to be very weak but you should try.

Then, if you set large Interleave and FEC=3 ask somebody to make
burst noise or make it yourself with a bad lamp switch :-)
The packets should still come through...

With FEC=3 and Interleave=16 you can withstand 3*16/2 = 24 symbol
burst error - this makes 24/83.33 = about 0.3 second.
A good example of a burst errors is when you hear a distant lighting storm
 - the static crashes can blank any signal for a fraction of second
 - well, sometimes for a few seconds :-)

> My results: with normal usb and width/shift knobs as they were during
> fec 3 testings i got results between 2.1 khz and  2.3 khz !!!
> I know that with width/shift knobs i can change this a little.

For me the points where the S-meter falls down by 1S are:
29.999.6 and 29.997.2 thus I get 2.4 kHz at -6dB.
The passband center is at 29.998.4 which corresponds to the audio
frequency of 1600 Hz (if the tranceiver is aligned right).

I have placed the modem's center carrier on 1625 Hz - so for me
it all right, for you... I don't know :-)

The modem in principle needs at least 15 carriers * 125 Hz/carrier = 1875 
Hz.
Because the symbol shape is rather short it spreads a bit more over
the frequency so it would be better to have about 2100 Hz.
The problem is that you don't know where this 2.1 kHz is located in your
radio (where is its center). In the receiver you can adjust the band's
center but for the transmitter you probably cannot.
On the diagram of the FT757 I can see that during transmit, the IF shift
is forced to a certain voltage regardless of the IF shift knob setting.
Would be nice to have a tool to measu the transmitter response and place
the signal's spectrum at the best position.

I could let the DSP send a series of tone of different frequency
and you could watch the power-meter for amplitude changes. Then
you could find out the passband edges and the center ?
This sounds like a good test to let us understand where is the problem.

By the way, you can try the LSB mode - I am sure the response is going
to be different :-) and the result may come out better.

Pawel
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From: Pawel Jalocha
To: Joni Becklund; Timo Sivula; Danie Brynard; Frode Weierud; Johan Forrer; 
Jarkko Vuori
Subject: Various comments on the newqpsk
Date:  23. August 1995 21:57

Hi to all !

Joni just told he made some successfull tests with Timo !
He asked some questions and I thought the answer would be
interresting to all people involved...
I hope Joni doesn't mind that I have included his words here...

>Modem works best when fec mode 3 is active. We tested it without
>fec and it worked with about 30-40% repeats so wi think that ft757
>filters are too narrow for it anyway...

FEC=3 has best correcting capabilities, so this is no suprise.
The reason for many errors with no FEC I can see two:
1. the filters are too narrow so the carriers on the edge get
   many symbols corrupted.
2. The spikes of the modem's waveform are cut off by the transmitter
   and this makes lot of errors on all carriers.
   The only cure for now is to lower the driving level - this lowers
   the output power too...

>Intresting point is that fec mode 1 did't work at all.. dcd flickers etc...

This I don't understand at all, please see if the modem works with FEC=1
in loopback. I could have screwed up something with FEC=1 in the recent
version. In principle if FEC=0 works then FEC=1 should work too
and much better.

>With fec 3 we had nice qso and we down/uploaded some files without
>any repeats. Signal levels during test were 59+ - 57 ....

You didn't do very high speed but it's a great thing !
In next tests you could try to lower the power and see how much
you can go down before you start missing the packets.

>We tested modem also while txjam was 4 and txtunelen/txsynclen 16..
>
>It worked fine like this also.

I understand you tried to lower these numbers for lower overhead
due to preambles and post-ambles.
Did you modify the corresponding receiver parameters like RxMinTune ?

>Timo has some problems with his receive, he said that dcd flickers
>when packets are received... Mine worked like this: at the beginning
>the dcd is steady the it goes off and comes on again and says on
>until hole packet/s are gone. So i think this dcd-off state is when
>txtune/sync off and packet starts ?? Im not sure but with short packets
>this point is abt half on hole packet lenght.

I should explain here the details... when the receiver detects
the tune preamble it turns the LED on. Then, it keeps the LED on
while it receives the symbol-sync preamble. Now, when it goes into
data more the LED is switched on or off depending on the FEC decoder
errors.
Note that just after the receiver switches to the data mode there are
only the four sync. tones active thus the received data is mostly garbage
thus the FEC finds error and the LED is off. Then, when all 15 tones come up
there is still some time left before the interleaver fills up. Only after
some time (propotional to the "Interleave") the FEC decoder gets a 
reasonable
data so the LED comes up again.

I would say Joni's LED behaved exactly as it should and no flickering
ment almost perfect data. Timo's red was flickering - thus this was
either his received (audio level too high or too low) or Joni's transmitter
drive level or something in the filters or the frequency error to high ?
IF shift maybe on Timo's side ?

Timo could try to use the AGC - I think is pretty safe if you don't want
to play with setting the gain right. Joni could try to lower the transmitter
level.

>So I would say that is WORKS !!! but I must say that it would be instesting
>to measure ft757 and its receiver on sbb... I mean how big differencies
>there are in signal levels when testing hole sbb bandwith.

>From what I see on my FT757 the ssb filter passes the audio from 200-300 Hz
to 2700-2800 Hz at -6dB. I measure this by turning the calibrator on and
tuning between say 29100 and 29103 kHz and observing the S-meter.
This is not bad at all... but, the audio filters after the SSB demodulator
make a strong dumping of high frequencies, the band 500-1000 Hz is passed
well but the 2700-2800 Hz band is attenuated by about 3 times (9dB).

>ps. maybe we could to some testing to africa later ;-)

We will all hold our breaths :-)

Pawel
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From: Pawel Jalocha
To: Timo Sivula <Timo.Sivula@ntc.nokia.com> Danie Brynard; Frode Weierud; 
Pawel Jalocha; Jarkko Vuori; Joni; Johan Forrer
Subject: Re: Various comments on the newqpsk
Date:  24. August 1995 10:00

Hello,

> We tried reducing the mic gain at Jonis end without any change. We used
> txattenuate 20 dB. I noticed that the best recption I  got when Jonis TX 
was
> on
> very low power, he had his microphone disconnected and I had the RF gain
>  attenuating
> so that there was very little noise coming trough and the level low. What 
is
> the level coming
> out of the modem? Could it be possible that the signal gets distorted at 
the
> TX
> already _before_ the mic gain potentiometer?

I didn't measure the modem's output level but it should be around 500 mV
and the 20.0 dB attenuation would divide this by 10 thus making 50 mV.
If you think it is too much just put more attenuation... 40 dB = 100 times
=> 5 mV output. The thing is I don't know how much noise is present
on the CODEC's output...

> I tested both with the AGC on, and without it. No big difference. It is
> clear that there
> were errors in the signal coming trough as the red led flickered when 
Jonis
> modem
> transmitted. The QSO was perfect however, because the  fec corrects these
> errors.
> In real HF conditions I do not think that this modem would work very well.
> I agree with Joni in that one propable problem is the receiver bandwidth. 
I
> tried
> playing around with the shift and width knobs but they did not help the
> situation at all.

The width knob ? You mean maybe the notch knob inside the shift knob ?
This one should be switched off - otherwise it notches out a piece
of the passband.

To judge the modem performance you could make a comparison test:
With FEC=3 see at which power you can reliably communicate.
Then try to make a packet QSO with a standard 1200 bps modem
(maybe you need to switch to FM...) and see again how much
power you need now ?

> The only thing that made any difference was using the RF gain to attenuate
> the incoming
> signal, this improved the LED behavior. This would imply some form of AF
> level related
> problem.

Wasn't the noise blanker turned on maybe ? It could clip and blank pieces
of the signal. I would try both slow and fast AGC setting too.

> FEC1 seems not to be working very well, I have not made any loopback tests
> yet. I think
> that the error correcting is not powerful enough to correct the errors 
that
> FEC3 manages
> to correct. I could copy a few of Jonis packets but he did not copy
> anything. There might
> also be something wrong with the algorythm, too. Have you made loopback
> tests with it, Pawel?

Yes, I have done tests yesterday and FEC=1 makes a much better copy
than FEC=0 in the presence of noise. I agree that FEC1 isn't as good
as FEC3 but what I don't understand is why FEC1 is worse than FEC0 ?

> The modem worked great with FEC3, the qso was like any packet QSO, not
> better not
> worse. I would say that the improvement to the earlier versions is huge.
> Congrats Pawel,
> you are coming very close to it now! It might need be wise to maybe remove
> one carrier?
> This would squeeze the thing a little and it might fit better into the 
used
> bandwidth?

If I remove one carrier, we can only work with FEC=0...
I see if I could easily remove maybe two "edge" carriers.

The other reason for our problems can be that my front FIR filter is
too narrow... this would cause problems when the tranceivers are miss-tuned
by too much. Please try the next time to change slighly the frequency
and see if this improves the error rate.

If you connect two LEDs to the UP/DOWN outputs (next to the PTT output)
you will notice if the modem is misstuned by more than 20 Hz and in
which direction. Better yet, connect these lines to the up/down pins
of the microphone socket of the FT757 - and the DSPCARD4 will
should correct the error automatically at the end of every transmition.
This have never been tried however :-)

> >>ps. maybe we could to some testing to africa later ;-)
>
> I've hear rumours of this. Could somebody inform me a little, too? I would
> very much like to join these tests.

Just make an appointment with Danie !

A question to Timo: with T4 can you give an arbitrary KISS command ?
I am working on switching the FEC and Interleave via a KISS command
so you can do it on-line during a connect as to quickly find the best
setting. For eexample I would made FEC switchable with parameter 20
and the Intnerleave with parameter 21. Other things (TxAttenuate for
example) could be made switchable too.

Pawel
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From: Pawel Jalocha
To: Danie Brynard; Joni Becklund; Timo Sivula; Johan Forrer; Frode Weierud
Subject: Program to test transmitter passband
Date:  25. August 1995 0:48

[[ TXTEST.ZIP : 2398 in TXTEST.ZIP ]]
So, I have written a simple program to "measure" the passband of your
tranceiver's transmitter. How to use it:

 - Compile the source and load the .LOD into the DSPCARD4/EVM56K.
  You will hear a tone in your headphones.
 - Start any terminal emulator, set it to 19200 bps, 8-bits, no parity
  and the serial port which is connected to the DSP's SCI.
  With <,>,[,],{,} you can change the tone's frequency and you can see
  it's current frequency on the monitor.
 - Connect the DSPCARD/EVM56K to the transceiver (PTT and MIC lines).
  Push "p" - and the DSPCARD4 will key the transmitter (dummy load !).
  Set a low power level (5-10W) and the meter into such mode so you can
  observe the RF output power.
  Pushing "p" once more switches the transmitter off.
 - Now you can vary the tone around and see how the output power changes.
  Notice the edges where the power quickly drops out and notice too
  how the passband looks like, whether it is flat o sloppy.

My passband begins at about 400 Hz and looks flat up to 1000 Hz,
then if falls down slowly but systematically. The upper edge apears
at about 2700-2800 Hz.
I must say I don't like this... for the receiver's non-flat passband
I didn't care so much, but if the transmitter makes the same, the upper
carriers are going to be much weaker on the air than the lower ones
and this will truly affect the error rates. What can we do about it ?
For now I can see only one solution: pre-amplify some carriers before
transmition (a very easy thing to do).

I suggest that now everybody should measure his transmitter
and put down the output levels for various frequencies
 - ideally for every carrier being used by the modem.
If this is done we can put the numbers into the newqpsk.bas
as to generate a set ot tones which would have equal amplitudes
at the antenna socket.

Pawel

section 1 of uuencode 5.02 of file txtest.zip    by R.E.M.

 ----------------------------------------------------------------------------  
 --
This uuencoded part of the message containing the file txtest.zip has been
decoded and converted into an attachment.
 ----------------------------------------------------------------------------  
 --
sum -r/size 10413/3479 section (from "begin" to "end")
sum -r/size 38585/2505 entire input file


The following binary file has been uuencoded to ensure successful
transmission.  Use UUDECODE to extract.
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From Sivula@ncsmsg01es.ntc.nokia.com Mon Aug 28 10:36:19 1995
Received: from axl01it.ntc.nokia.com (axl01it.ntc.nokia.com [131.228.118.232]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id KAA00612 for <hfsig@tapr.org>; Mon, 28 Aug 1995 10:36:10 -0500
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	id <30418CED@ntcite01es.ntc.nokia.com>; Mon, 28 Aug 95 11:31:25 eet
From: Sivula Timo <Sivula@ncsmsg01es.ntc.nokia.com>
To: "'HFSIG'" <hfsig@tapr.org>
Subject: FW: Various comments on the newqpsk
Date: Mon, 28 Aug 95 11:18:00 eet
Message-ID: <30418CED@ntcite01es.ntc.nokia.com>
Encoding: 243 TEXT
X-Mailer: Microsoft Mail V3.0



 ----------
From: Sivula Timo
To: Pawel Jalocha; danie.brynard; Frode Weierud; Jarkko Vuori; Joni; Johan 
Forrer
Subject: Re: Various comments on the newqpsk
Date:  25. August 1995 9:35

Hello!

First: Should we either move this discussion to the hfsig group, or create a 
new group
for DSP56k qpsk testing and reporting? I suggest this, as I am getting fed 
up with this
carbon copying every time :-)

I will comment the latest three messages from Pawel in this one and only 
message, as I think
it is easier and the topic is of interest to all involved here.  The message 
is quite long,  I am
afraid. Maybe I should have kept it in three parts anyway... I have some 
really weird ideas presented in the end of the message...

 ----------
>Subject: Re: Various comments on the newqpsk
>Date:  24. August 1995 10:00

>If you think it is too much just put more attenuation... 40 dB = 100 times
>=> 5 mV output. The thing is I don't know how much noise is present
>on the CODEC's output...

How does the headphone output relate to the line output? At least the 
headphone
output is quite noisy. Do you think that 50 mV could get distorted in the 
mic preamp?

>The width knob ? You mean maybe the notch knob inside the shift knob ?

Both Joni and I are using the FT757 GX MK I and it does not have a notch, 
instead
there is a shift function where the MK II has a notch.

>To judge the modem performance you could make a comparison test:
>With FEC=3 see at which power you can reliably communicate.
>Then try to make a packet QSO with a standard 1200 bps modem
>(maybe you need to switch to FM...) and see again how much
>power you need now ?

This seems like a good idea, the only problem is that as far as I remember 
Joni
reduced the output power until it could not get less, and it still worked 
ok. The 757
has quite good dymaics in what comes to setting the TX output. Remember that
we are only 10 km apart.

>Wasn't the noise blanker turned on maybe ? It could clip and blank pieces
>of the signal. I would try both slow and fast AGC setting too.

No noiseblanker was used, and I tested both slow and fast AGC.

>Yes, I have done tests yesterday and FEC=1 makes a much better copy
>than FEC=0 in the presence of noise. I agree that FEC1 isn't as good
>as FEC3 but what I don't understand is why FEC1 is worse than FEC0 ?

This is what I suspected. We did not do any long tests with FEC=1, so our 
report
is not 100% valid. I guess that it simply did not manage all errors that 
were on
the signal. FEC=3 could. Or we didn't tune it long enough.

>If I remove one carrier, we can only work with FEC=0...
>I see if I could easily remove maybe two "edge" carriers.

Too bad.

>The other reason for our problems can be that my front FIR filter is
>too narrow... this would cause problems when the tranceivers are miss-tuned
>by too much. Please try the next time to change slighly the frequency
>and see if this improves the error rate.

We did tune a lot, but there was no big difference in the result.

>which direction. Better yet, connect these lines to the up/down pins
>of the microphone socket of the FT757 - and the DSPCARD4 will
>should correct the error automatically at the end of every transmition.
>This have never been tried however :-)

I think this is the next step we will test. I'll have to find out a neat way 
to
connect the up & dwn buttons to the rear of the rig, so that I will not have 
to
connect it to the mic. An other solution would be using a mic plug to feed
the AF in to the rig, not the AFSK/PATCH socket in the back of the rig. This 

way I could connect the DSP4 directly to the mic socket. I even have a spare
microphone plug that I could solder in. Hmmm, I think I'll try this. Does 
anybody
know if there is any AF out in the mic socket of the 757, so that I could 
connect
all lines to the one and same plug?

>A question to Timo: with T4 can you give an arbitrary KISS command ?

Sorry, no. T4 runs on a TheFirmware TNC, and I have to use a KISS emulator
(TFKISS) to interface T4 to an non TF TNC.

>I am working on switching the FEC and Interleave via a KISS command
>so you can do it on-line during a connect as to quickly find the best
>setting. For eexample I would made FEC switchable with parameter 20
>and the Intnerleave with parameter 21. Other things (TxAttenuate for
>example) could be made switchable too.

Why not make this automatic instead? Let the modem collect the number of
errorcorrections and then according to some trig-levels switch automaticly
to a less complicated FEC and higher speed if the link permits it, and vice 
versa.
You only need to find out how to tell the other modem about the mode 
change... ;-)
but with 15 tones to choose from that should not be too difficult, I hope.

Now the modem would autotune and fit the errorcorrecting code according to 
the
band conditions, what say?

Now to the second mail:

>Just a piece of my discussion with Joni, I thought it could be 
interresting.

>> Yep, but it works well with FEC 3 and we tested this spy thing you
>> tols us to do, Timo had problems with his spy and it made 8 MB files on
>> hid HD ;-)... user error who knows ;-)
>
>This is very funny... for me the SPY makes a file of 512 lines and there is
>one decimal number in every line. I never had problems with that.

Hey guys, tell me how to use this spy-thing!  Here are the original notes by 

Pawel and my comments:

>Timo will do the following:
>- compile the source with SPY=1 and SPY_RxCrossedIQ=1
>- disconnect the PTT and MIC lines from the tranceiver
>  because with SPY=1 the modem transmits random data packets.
>- load the .LOD file into the his DSPCARD4

All the previous went fine.

>- start the SPY.EXE (supplied with the DSPCARD4 tools) like this:
>  spy -p2  (-p2 means the DSPCARD4 is on the COM2)

I have my DSP on COM 1 so I used SPY -p1, and I tested also just SPY.
The program started ok.

>- press "s" when Joni's beacon comes and the red LED flickers.

I pressed s once and there was indeed a funny colored figure on the screen.

>  After a moment Timo will get some funny data displayed on his screen.
>- press "w" to save this data into a log.dat file.

Here came the Problems. I pressed w once, and the hard disk started running.
And it did not stop, not until I forced the system down with ctrl-alt del. 
When I then
checked what I had made there was a 9 MB file calle log.dat. This I can not 
send
to you ;-) What does the S do? What happens when I press w, or what should 
happen?
How does this SPY work?

>By the way, you can try the LSB mode - I am sure the response is going
>to be different :-) and the result may come out better.

This we have not tested with the latest version.

>So, I have written a simple program to "measure" the passband of your
>tranceiver's transmitter. How to use it:

I will be out of town for the weekend but this test seems to be a good one. 
I'll
run it when I get back on monday. Could you make the test soft so that one
could give the modulating tone directly as a number? Like 100 (enter) would
give 100 Hz,  3000 (enter) would give 3 kHz? This would be very useful for
other applications as well... A settable sinewave generator on the DSP4!

>My passband begins at about 400 Hz and looks flat up to 1000 Hz,
...
>I must say I don't like this... for the receiver's non-flat passband
>I didn't care so much, but if the transmitter makes the same, the upper
>carriers are going to be much weaker on the air than the lower ones
>and this will truly affect the error rates. What can we do about it ?

Pawel, excuse me for my mad ideas but... Could this be done?

Make one of the preamble tones being in the high end of the pass band. Like 
1500
and, or why not using 3 or more tones.

The receiving modem, during tune phase, measures the level difference 
between this
tone and a tone in the "flat" response area. The dummy bits (pre/post data 
or whatever
they are called) is then used to send the measurement data in the next 
transmission
back to the other end.

The modems would monitor the upper end of the AF spectrum all the time and 
adjust the
levels according to what it gets form the other end. I guess that 
quantizizing with 4 bits
might be enough? One could assume that the passband is flat to 1 kHz, and 
quantizize the
difference between this "flat" level and the high end level. If one asumes a 
linear decay
of the response from 1 kHz upwards only the highest tone has to be 
monitored, and a
linear correction from 1 kHz to the upper frequency would be calculated.  If 
the linear
assumption is too inaccurate, why not measure more tones?

>For now I can see only one solution: pre-amplify some carriers before
>transmition (a very easy thing to do).

How about automating this, too like above? Is it possible? How much 
processing power
would this correcting need if it would be done "live"? This feature could 
also help against
selective fading in some cases on HF. The correction could of course either 
be done at the
receiver or the transmitter end, or why not both? I would prefer the TX side 
as this would
increase the S/N of the higher tones.

>I suggest that now everybody should measure his transmitter
>and put down the output levels for various frequencies

Yep, and if a common knee point (1 kHz?) is found it could be used
as the other end of the linear correction... :-)

What do you think?

73, Timo
From karn@qualcomm.com Mon Aug 28 18:45:09 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id SAA07044 for <hfsig@tapr.org>; Mon, 28 Aug 1995 18:45:02 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id PAA22381; Mon, 28 Aug 1995 15:55:55 -0700
Date: Mon, 28 Aug 1995 15:55:55 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508282255.PAA22381@servo.qualcomm.com>
To: hfsig@tapr.org
Cc: antonio@qualcomm.com
Subject: FFT progress

I thought the group might be interested in my progress on FFT code for
the Intel machines. Franklin Antonio N6NKF and I are in a little
friendly competition to see who can do the fastest FFT on a 90 Mhz
Pentium. He's using Windows and the Watcom C compiler while I'm using
BSDI 2.0 and GCC 2.6.3.

So far Franklin has been a little ahead of me. From looking at the asm
code his compiler produces, it looks like it knows how to optimize for
the Pentium, unlike my version of GCC.

So I've been writing some of the butterflies by hand in assembler with
careful attention given to keeping the floating point pipeline full
(which is harder than it sounds given the baroque Intel architecture).

I now have a single precision floating point radix 4 butterfly w/o
twiddles executing in about 0.71 microseconds.  That's about 56
megaflops on average counting only "real" floating point instructions
(fld, fsto, fadd, fsub). By comparison, "straight" asm code written
without regard to pipelining takes about 1.3 microseconds.

When I integrated this into radix-4 DIF C code I'd already written so
that the asm routine is executed instead of C code in the last stage,
the overall time for a 256-point complex FFT is 485 microseconds.
(The pure C code was 525 us). That's better than a million samples/sec.

The next step is to write a general radix-4 butterfly that can handle
twiddle factors and arbitrary array stepping so it can be used in
stages other than the last. This should really get things humping.

Of course, I'm already about 100x faster than required by a spectrum
analyzer operating on SSB receiver bandwidths, but it *is* fun to see
just how fast you can go...

Phil



From jalocha@home-gate.ifj.edu.pl Tue Aug 29 08:29:00 1995
Received: from home-gate.ifj.edu.pl (home-gate.ifj.edu.pl [192.86.14.17]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id IAA15742 for <hfsig@tapr.org>; Tue, 29 Aug 1995 08:28:48 -0500
Received: from home.ifj.edu.pl by home-gate.ifj.edu.pl (JNOS1.10h) with SMTP
	id AA3388 ; Tue, 29 Aug 95 16:28:45 UTC
Date: Tue, 29 Aug 95 15:28:36 MET
From: "Pawel Jalocha" <jalocha@home.ifj.edu.pl>
Message-ID: <1036.jalocha@home.ifj.edu.pl>
To: hfsig@tapr.org
Reply-to: jalocha@home-gate.ifj.edu.pl
Subject: Multi-tone, DQPSK modem summary

Here is a short summary to keep all HFSIG'ers aware of what
is going on with the multi-tone DQPSK modem.

The modem has evolved to the following configuration:

Modulation type:

There are 15 tones ranging from 750 to 2500 Hz
spaced by 125 Hz. Each tone is modulated with DQPSK
(four states => 2 bits/symbol) at 83.33 symbols/second.
Raw data rate is 2500 bps.

Peak to RMS ratio (crest factor):

Not very good... about 4.0

Frequency error correction:

The receiver can correct a frequency error of up to +/- 60 Hz.
There are as well outputs provided for steering the transceiver's
UP and DOWN buttons for automatic frequency error correction.
This feature has not been tested yet.

Forward error correction:

What is implemented now is basically a block-type FEC with the block size
of 15 bits. Every bit of a given block is transmitted on a different carrier.
The intention is that a selective fading/interference would affect least
amount of bits in a block.
The bits of one block can be all transmitted at one time or they can be
spread out in time by an arbitrary factor.
This feature helps to recover burst errors if at one time all carriers
get wiped out by a spark or a lighting discharge.

The FEC schemes are:

Scheme #0: No FEC, effective data rate is 2500 bps.

Scheme #1: 11 "real" data bits + 4 CRC bits form a 15-bit block.
           The receiver can correct one flipped bit per 15-bit block
           Effective data rate is 2500*11/15 = 1833.33 bps

Scheme #3: 5 data bits are mapped into a 15-bit codeword from a set
           of 32 codewords with the hamming distance greater than 7
           between each two selected from the set. These are infact
           Walsh functions.
           The receiver can correct up to three flipped bits per
           15-bit block.
           Effective data data is 2500*5/15 = 833.33 bps

Hardware platform:

The code is being developed on a DSPCARD4 by ALEFNUL (credits here
to Jarkko Vuori and Kaj Vik) but it runs as good on the EVM56002
from Motorola (thanks to Johan Forrer who ported the DSPCARD4's
basic system).

Communication protocol:

The modem understands KISS, thus it is oriented towards sending frames.
These can be AX.25 frames but in principle there is no real limit here,
as KISS can carry any frame.

Some real on-air tests have been done already by Timo and Joni
on a short (10-15 km) HF range. AX.25 protocol was used.
The result... well, the modem works, especially when you use the FEC
scheme #3. There are certainly troubles and they concentrate around
the tranceiver's passbands and driving levels. This you can see better
from Timo's postings :-)

A modem version exists already which switches the FEC schemes and Interleave
factors according to KISS commands. However, to my big surprise, I found
that the packet-radio software I have can not issue an arbitrary
KISS command ! For example JNOS:

I say: param tnc 12 3

NOS says: parameter 12 not supported

I have to ask the JNOS writers to fix this bad feature.

Future plans ?

- Double the number of carriers and then I can use the block size
  of 60 bits which is suitable for RS codes with 4-bit symbols.
  The alternative is to add a block-sync sequence and then you can use
  FEC with any block size.

- Use longer FFT and better window to make the symbols "narrower" in
  frequency. The ones I use now have significant sidelobes.

It would be certainly helpfull to have more testers, thus anybody
willing to join please stand up ! You need a shortwave tranceiver,
a PC, and a DSPCARD4 or an EVM56K.

Pawel


From FORRERJ@frl.orst.edu Tue Aug 29 10:39:39 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id KAA17443 for <hfsig@tapr.org>; Tue, 29 Aug 1995 10:39:34 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id IAA19003 for <hfsig@tapr.org>; Tue, 29 Aug 1995 08:39:29 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21);
    29 Aug 95 08:46:07 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 29 Aug 95 08:45:52 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 29 Aug 1995 08:45:45 PST8PDT
Subject:       Re: [HFSIG:562] Multi-tone, DQPSK modem summary
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <BA8FE46747@frl.orst.edu>

Pawel,

Thank you very much for the summary of the parallel modem. Congratulations 
is also in order on this fine achievement. What is perhaps not so obvious is 
the complexity of this software - for those that are planning on attending 
the DCC, I hope to devote a bit of time on the modem's software 
and working principles at the DCC. The system will also be on demo to 
give you an opportunity to see it in action and ask questions if you like.

Congratulations also goes to Joni and Timo for logging the first successful 
tests over the air. I realize that developments are in its infancy and 
there are lots of ideas for improvements.

To all the contributors to this project, your efforts are 
greatly appreciated - Keep up the good work.

--Johan, KC7WW

P.S. Would you mind if we share your summary with others in the next PSR? I 
have a few other items that I will include in the HFSIG summary.


From FORRERJ@frl.orst.edu Tue Aug 29 10:43:10 1995
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id KAA17488 for <hfsig@tapr.org>; Tue, 29 Aug 1995 10:43:02 -0500
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu (8.6.9/8.6.9) with ESMTP id IAA19042 for <hfsig@tapr.org>; Tue, 29 Aug 1995 08:42:58 -0700
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.21);
    29 Aug 95 08:49:35 PST8PDT
Received: from MERCURY_MAILER by FRL (Mercury 1.21); 29 Aug 95 08:49:10 PST8PDT
From: "Johan Forrer" <FORRERJ@frl.orst.edu>
Organization:  Forest Research Lab. Oregon State
To: hfsig@tapr.org
Date:          Tue, 29 Aug 1995 08:49:08 PST8PDT
Subject:       Re: [HFSIG:561] FFT progress
Priority: normal
X-mailer:     PMail v3.0 (R1a)
Message-ID: <BA9DF76AC4@frl.orst.edu>

Phil,

Sounds an exciting devolpment. I would not be surprized at all to see some 
innovative DSP work being done on the faster Intel-based platforms in 
future. You certainly are making good progress towards that.

--Johan
From danie.brynard@pixie.co.za Tue Aug 29 23:53:47 1995
Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id XAA01251 for <hfsig@tapr.org>; Tue, 29 Aug 1995 23:53:42 -0500
Received: from pixie.co.za ([196.11.63.145]) by foxbat.pix.za (8.6.12/8.6.12) with SMTP id GAA07267 for <hfsig@tapr.org>; Wed, 30 Aug 1995 06:54:14 +0200
Date: Wed, 30 Aug 1995 06:54:14 +0200
Message-Id: <199508300454.GAA07267@foxbat.pix.za>
X-Sender: pak03226@pixie.co.za (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:551] I measured my RX


>I made the RX test this morning before leaving to the job. I made it in the 
>same manner as
>Pawel: I switched the marker generator on and tuned the rig around the 
>marking frequency.
>If I do not recall wrong, the S meter measures the input _voltage_  so that 
>one S-unit is 6 dB.

Thanks for the info. What marker generator are you talking about ? In any
case its a good idea. I will use a crystal based QRP rig I have here with
good phase noise and measure the receiver passband with. I think my rig can
step in 1Hz steps hi !

73 danie

From danie.brynard@pixie.co.za Tue Aug 29 23:53:53 1995
Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id XAA01263 for <hfsig@tapr.org>; Tue, 29 Aug 1995 23:53:48 -0500
Received: from pixie.co.za ([196.11.63.145]) by foxbat.pix.za (8.6.12/8.6.12) with SMTP id GAA07277 for <hfsig@tapr.org>; Wed, 30 Aug 1995 06:54:21 +0200
Date: Wed, 30 Aug 1995 06:54:21 +0200
Message-Id: <199508300454.GAA07277@foxbat.pix.za>
X-Sender: pak03226@pixie.co.za (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:561] FFT progress


>Of course, I'm already about 100x faster than required by a spectrum
>analyzer operating on SSB receiver bandwidths, but it *is* fun to see
>just how fast you can go...
>
Hi Phil

Your FFT programming for the pentuim etc is very interesting. I have always
been interested in building my own spectrum analyser. What about have a
pentuim + radio receiver with say 500kHz baseband bandwidth stepping in
500kHz steps from 100kHz to 2GHz. This would form a magnificent spectrum
analyser with unlimited resolution bandwidth ? (sweeps would get slower though)

For having a span wider than 500kHz one could sweep the radio with its RS232
port from the PC. I would suggest an AOR-3000A. It does 100kHz - 2.036GHz at
50Hz increments per second, if I can remember correctly)

I choose 500kHz 'cos it is half your current attainable sampling rate of
about 1MHz, not so ?

What do you say ?

73 danie zs6awk


From karn@qualcomm.com Wed Aug 30 01:41:15 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id BAA03723 for <hfsig@tapr.org>; Wed, 30 Aug 1995 01:41:12 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id XAA05311; Tue, 29 Aug 1995 23:41:10 -0700
Date: Tue, 29 Aug 1995 23:41:10 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199508300641.XAA05311@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <199508300454.GAA07277@foxbat.pix.za> (danie.brynard@pixie.co.za)
Subject: Re: [HFSIG:566] Re: FFT progress

>been interested in building my own spectrum analyser. What about have a
>pentuim + radio receiver with say 500kHz baseband bandwidth stepping in
>500kHz steps from 100kHz to 2GHz. This would form a magnificent spectrum
>analyser with unlimited resolution bandwidth ? (sweeps would get slower though)

Sure! Though I don't know how you'd display 500K points across a
typical video screen. I.e., although it could run in real time on a
Pentium, the analyzer would display data much faster than your eyes
could absorb it.

Lessee...if you drove a typical high resolution PC display at maximum
rate, how many samples/sec would that be? Well, a typical display is
now 1024 pixels across. 

Update that at 72 frames/sec and you have 73728 pixels (frequency
samples) per sec.  Even after scaling my FFT to 1024 points, it would
still take less than 10% of my Pentium 90. That leaves 90+% percent to
run the video display driver.

You can make each of those 1024 horizontal pixels cover whatever
frequency bin size you like, the FFT computation rate would be the
same. You could cover a total of 500 Khz across the display if your RF
and A/D converter bandwidth supports that, but then each bin would
cover 488 Hz, which might be too coarse for your taste. If you limited
yourself to a 10.24 KHz span you could get 10 Hz resolution, not counting
window effects.

Phil

From pe@paccomm.com Thu Aug 31 08:01:48 1995
Received: from paccomm.com ([163.125.30.1]) by sys1.tapr.org (8.6.12/8.6.9) with SMTP id IAA22072 for <hfsig@tapr.org>; Thu, 31 Aug 1995 08:01:33 -0500
X-BBS-Msg-Type: P
Date: Thu, 31 Aug 95 08:55:20 UTC
Message-Id: <4823@paccomm.com>
From: pe@paccomm.com
To: hfsig@tapr.org
Subject: Re: [HFSIG:546] Re: Robust modems
In-Reply-To: your message of Wed, 23 Aug 1995 14:24:49 -0500.
             <4243@paccomm.com>


You might also try talking to Bath University - they always
had a very strong HF group, unless the academics have moved
on.......

From karn@qualcomm.com Thu Aug 31 20:33:13 1995
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id UAA01949 for <hfsig@tapr.org>; Thu, 31 Aug 1995 20:33:10 -0500
Received: (karn@localhost) by servo.qualcomm.com (8.6.12/QC-BSD-2.5.1) id SAA26206; Thu, 31 Aug 1995 18:33:09 -0700
Date: Thu, 31 Aug 1995 18:33:09 -0700
From: Phil Karn <karn@qualcomm.com>
Message-Id: <199509010133.SAA26206@servo.qualcomm.com>
To: hfsig@tapr.org
In-reply-to: <BA9DF76AC4@frl.orst.edu> (FORRERJ@frl.orst.edu)
Subject: Re: [HFSIG:564] Re: FFT progress

Johan,

Thanks. I've since gotten the 256-point CFFT time down to 380 us, and
I think there's *still* room for improvement. I'm doing the simple
radix-4 butterfly in 24 adds/subtracts, when I know I can do it in
only 16 by taking advantage of common subexpressions. ("Simple"
butterfly means unity twiddles. I have a separate function that does a
general purpose butterfly with non-unity twiddles that takes a little
longer.)

The big problem is in keeping the Pentium's 3-stage floating point
pipeline full.  Floating point add, subtract and multiplies all take 3
clocks to execute from start to finish, but you can stage 3 operations
in parallel and retire one instruction per clock if you are careful
not to stall the pipeline by using the result of an operation as an
operand to a subsequent instruction that starts less than 3 clocks
later. This is a fun challenge very much akin to juggling with three
balls in the air at once...

Phil

From danie.brynard@pixie.co.za Thu Aug 31 23:42:41 1995
Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id XAA04324 for <hfsig@tapr.org>; Thu, 31 Aug 1995 23:42:35 -0500
Received: from pixie.co.za ([196.11.63.140]) by foxbat.pix.za (8.6.12/8.6.12) with SMTP id GAA10424 for <hfsig@tapr.org>; Fri, 1 Sep 1995 06:43:12 +0200
Date: Fri, 1 Sep 1995 06:43:12 +0200
Message-Id: <199509010443.GAA10424@foxbat.pix.za>
X-Sender: pak03226@pixie.co.za (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:562] Multi-tone, DQPSK modem summary

>Here is a short summary to keep all HFSIG'ers aware of what
>is going on with the multi-tone DQPSK modem.
>

....

>It would be certainly helpfull to have more testers, thus anybody
>willing to join please stand up ! You need a shortwave tranceiver,
>a PC, and a DSPCARD4 or an EVM56K.
>
Hi Pawel

Thanks for this. I am slowly cathing up. I am currently not able to tx from
NOS using NEWQPSK.ASM

danie

From danie.brynard@pixie.co.za Thu Aug 31 23:43:01 1995
Received: from foxbat.pix.za (foxbat.pix.za [196.11.62.105]) by sys1.tapr.org (8.6.12/8.6.9) with ESMTP id XAA04337 for <hfsig@tapr.org>; Thu, 31 Aug 1995 23:42:51 -0500
Received: from pixie.co.za ([196.11.63.140]) by foxbat.pix.za (8.6.12/8.6.12) with SMTP id GAA10457 for <hfsig@tapr.org>; Fri, 1 Sep 1995 06:43:28 +0200
Date: Fri, 1 Sep 1995 06:43:28 +0200
Message-Id: <199509010443.GAA10457@foxbat.pix.za>
X-Sender: pak03226@pixie.co.za (Unverified)
X-Mailer: Windows Eudora Version 1.4.4
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
To: hfsig@tapr.org
From: danie.brynard@pixie.co.za (Danie Brynard)
Subject: Re: [HFSIG:567] Re: FFT progress

Thanks Phil for the Spectrum analyser thoughts. Another solution to a
personal spectrum analyser for a radio ham would be using a AOR AR-3000A
(100kc-2GHz) scanner + PC with s/w or the new Trident 1MHz to 1GHz scanner
which even supports a analog X-Y signal out to an oscilloscope. PC's are
nasty things in a RF lab. They make a hell of a lot of noise... Anybody
who's doing that ?


73 danie zs6awk

